Operations and workflow systems
The core system for how work moves through your business — the one the ERP covers 70% of and the remaining 30% runs on email.
Order to dispatch, including the approvals the ERP has no concept of.
Capability
Custom Software Development Services
The operational system underneath — the one the packaged software did not cover. Built around your process rather than configured around someone else’s, in React and Django, and handed over with the documentation to maintain it without us.
From $14,000 · 8–12 weeks · fixed scope, agreed in writing
- To a system in production
- 8–12 weeksTo a system in production
- Source code ownership
- 100%Source code ownership
- Our strongest ground
- React + DjangoOur strongest ground
- Handover, not dependency
- DocumentedHandover, not dependency
What your team gets
What is actually delivered
Not a strategy deck. A running system, the permissions around it, and the code in your repository.
- A system built around your process, not a configuration of someone else’s
- One source of truth, with the spreadsheets that shadowed it retired
- Integrations with the systems you keep — ERP, payments, accounting
- Role-based access that matches how your organisation actually works
- Full source code, documented, in your repository, with tests
- A maintenance path that does not depend on us continuing to exist
What we build
Six systems we build most often
All of them start the same way: a packaged product covers most of the job, and the part it misses is the part the business actually runs on.
Member and customer portals
Self-service for the people who currently email your office, with the records behind it staying in one place.
A portal serving 10,000+ members, delivered in four months including migration.
Internal tools and admin
The back office your team lives in all day, designed so the twentieth repetition is as fast as the first.
A dispatch desk where a saved click compounds across a thousand orders.
Reporting and dashboards
Numbers your team trusts because they come from the system rather than from a manual export somebody maintains.
Branch performance visible daily instead of at month end.
Integration platforms
A middle layer where several systems have to agree, with the reconciliation logic in code rather than in a person’s head.
Storefront, ERP and accounting kept in step continuously.
Legacy replacement
Taking over a system whose original developer is gone, running the two in parallel, and migrating without a weekend of downtime.
A decade-old internal app replaced module by module.
How we build it
How we build something that is still maintainable in year three
Most custom software is not abandoned because it stopped working. It is abandoned because nobody can safely change it any more. Every decision here is aimed at the third year, not the launch.
- 01
Model the domain first
The data model is the thing you cannot cheaply change later. We spend real time on it with the people who know the business, before any interface is drawn.
- 02
One API, several clients
Web, mobile and partner integrations all enter through the same API with the same rules. Business logic never lives in a screen, which is how two clients start disagreeing.
- 03
Boring, well-lit technology
Django and React, PostgreSQL, Celery. Chosen because your next developer will already know them and because they will still be maintained when the current fashion is not.
- 04
Tests where they earn their place
Heavy coverage on domain rules and money, light on the presentational layer. A test suite nobody trusts is worse than none, because it gets skipped rather than fixed.
- 05
Handover as a deliverable
Documentation, environment setup, a runbook and a walkthrough with whoever will maintain it. If your team cannot run it without us, we have not finished.
Build or buy
We would rather tell you the package wins than build something you later regret. Before quoting a custom build we name the closest product, verify what it genuinely cannot do, and compare three years of cost on both sides including maintenance and dependency on us. Custom is right when the process is genuinely yours and the mismatch is structural — not when a configuration screen is unfamiliar.
- Structural gap
- The process cannot adapt to the product.
- Competitive edge
- The process is why you win.
- Integration weight
- Several systems must agree.
- Three-year cost
- Compared honestly, both ways.
How we avoid the rewrite
Systems become unmaintainable through accumulated exceptions nobody documented, business logic scattered across screens, and a test suite that stopped being trusted. We keep rules in one layer, keep the data model clean enough that new requirements are additions rather than surgery, and treat documentation as part of the definition of done.
- One rules layer
- Not duplicated per screen.
- Migrations
- Versioned, reversible, reviewed.
- Trusted tests
- Where they catch real regressions.
- Docs in the repo
- Beside the code, not in a drive.
Where AI fits into a custom build
Increasingly the system is the platform an agent later acts on. We build the API and permission model so that adding an agent afterwards is a small project rather than a re-architecture — even when AI is nowhere in the current scope. It costs nothing now and saves a great deal later.
Where it lands
What this looks like in your industry
Institutions and membership
Member portals, chapters, renewals and the records behind them, in one system.
Manufacturing
The production and stock logic the ERP does not model, connected to the ERP.
Distribution and logistics
Dealer ordering, allocation and delivery tracking across branches.
Hospitality and restaurants
Floor operations that need software and hardware to agree, down to the firmware.
Real estate and PropTech
Listings, enquiries and site visits in one place instead of three.
FinTech and financial services
Operational systems around a regulated core, with auditability designed in.
Technology
What we build agents with, and what we connect them to
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Backend
- Django
- Django REST Framework
- FastAPI
- Node.js
- Celery
- Python
- Frontend
- React
- Next.js
- TypeScript
- Tailwind CSS
- TanStack Query
- Data
- PostgreSQL
- Redis
- S3
- Elasticsearch
- Alembic / Django migrations
- Integrations
- Stripe
- SSLCommerz
- Twilio
- SendGrid
- SAP Business One
- Zoho
- QuickBooks
- Infrastructure
- Docker
- AWS
- GitHub Actions
- Nginx
- Terraform
- Quality
- pytest
- Playwright
- Ruff
- ESLint
- Sentry
- OpenTelemetry
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 0
Discovery call
What the process is, what currently fails, and whether a packaged product would do it better. Thirty minutes, and a straight answer.
DeliverableA written next step, free - 02Weeks 1–2
Discovery and scope
Process mapping, the domain model drafted with your team, integration constraints tested, and the scope written down with a change process agreed.
DeliverableWritten scope, domain model, fixed quote - 03Weeks 3–8
Build in slices
Vertical slices delivered to a staging environment every two weeks, so you are using something real long before the end rather than reviewing screenshots.
DeliverableWorking software in staging, every fortnight - 04Weeks 9–10
Migration and UAT
Data migrated and reconciled, your team testing against real records, and the fixes that come out of that.
DeliverableMigrated data, signed-off UAT - 05Weeks 11–12
Launch and handover
Go-live with monitoring and a rollback path, then documentation, a runbook and a walkthrough with whoever maintains it.
DeliverableLive system, source code, docs, runbook
Why Devs Core
Six reasons that are checkable
This is our strongest ground
React and Django web applications, PM-led discovery, and maintainability. Most of the 32+ projects we have delivered are this shape.
We will tell you to buy instead
If a packaged product covers it, the honest comparison says so. That has cost us builds and earned us the call when the product later failed.
You use it before the end
Vertical slices in staging every fortnight. Nobody should first see their system in month three.
Scope in writing, changes through a process
Agreed before work starts. Nobody discovers the budget moved in a status call.
Built so an agent can be added later
A clean API and permission model, even when AI is nowhere in the current scope. It costs nothing now and saves a lot later.
Handover is a deliverable
Documentation, runbook and a walkthrough. If your team cannot run it without us, the project is not finished.
Questions
Custom Software Development — the questions we get asked
When is custom software the right choice over a packaged product?
When the mismatch is structural rather than cosmetic — the process is genuinely specific to your business, it is part of why you win, or several systems have to agree in a way no single product covers. When a packaged product covers the standard version of the problem, buying it is usually right, and our readiness audit will say so.
How much does custom software development cost?
Custom software starts at $14,000 for a fixed scope agreed in writing, typically over eight to twelve weeks. The variables are the number of user roles, how many external systems must be integrated, and whether data has to be migrated from something existing.
What technology do you build with?
Django and React by default, with PostgreSQL, Celery and Redis, deployed in Docker on AWS. They are deliberately boring choices: your next developer will already know them, and they will still be maintained in five years. We use FastAPI where a service is AI-facing, and Next.js where the front end needs server rendering.
Who owns the code?
You do — 100%, documented, in your repository, with no licence fee and no runtime component we retain. Another team can pick it up without our involvement, which is the point.
Can you take over a system someone else built?
Yes, and it is common. We start by reading what exists and producing an assessment of what is worth keeping, what needs replacing and what it would cost — before agreeing to own it. Taking over a system without that assessment is how both sides end up unhappy.
How do you handle changes mid-project?
Scope is written down before work starts, along with the process for changing it. A change is priced and agreed in writing before it is built. This matters more than it sounds: most project disputes are scope disputes that were never written down in the first place.
What happens after launch?
Handover includes documentation, a runbook and a walkthrough with whoever will maintain it. Ongoing maintenance is available but never required — the deliverable is a system your own team or another firm could run.
Do you migrate data from our existing system?
Yes. Migration is scoped explicitly, run against a copy first, and reconciled record by record before cut-over. It is usually the most underestimated part of a replacement project, so we treat it as its own phase rather than as a task at the end.
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com