Custom software costs several times a website and takes months rather than weeks. It is occasionally the only honest answer, and more often it is not.
Custom software development covers internal tools, customer portals, web applications, SaaS products and API integration. It is justified when your requirements involve genuine business logic, roles and permissions, or integration depth that platforms cannot reach. For anything a configured platform already does, it is an expensive way to rebuild solved problems.
The spreadsheet that runs a critical process and breaks when two people edit it. Workflow, roles, audit trails and reporting, built around how the work actually happens rather than how a generic tool assumes it does.
Clients logging in to see orders, documents, tickets or account status. Most of the work is in the roles, the data model and integrating with whatever system already holds that information.
A different commitment from a portal: iteration, support, a roadmap and a team. We will be honest about whether you are resourced for that before starting, because a product without ongoing investment stalls.
Connecting systems that describe the same data differently. The engineering that matters is failure handling, retries and rate limits rather than the connection itself.
Before building we produce a written specification: rules, roles, data model, integrations and edge cases. You own it regardless of who builds from it, which also lets you get comparable quotes.
Architecture, setup and deployment documented as a deliverable. Undocumented custom code is a liability handed to whoever comes next, and it is how businesses end up locked to one supplier.
| Factor | Why it moves the number | What to ask |
|---|---|---|
| How many rules | Business logic is the bulk of the work | Are the rules written down yet? |
| Roles and permissions | Who sees and does what | How many user types? |
| Integrations | Each one is a project of its own | What connects, and what if it fails? |
| Data migration | Moving from whatever runs it today | How clean is the existing data? |
| Compliance obligations | Architecture, not a feature | What are we required to do? |
| Ongoing ownership | Someone maintains it or it rots | Who owns this in month twelve? |
We scope after a discovery engagement, which is separately quoted and produces a specification you keep. Pricing custom software before the rules are written produces a number that is wrong for both sides.
| Ask them | A good answer sounds like | Walk away if |
|---|---|---|
| Who owns the code and repository? | You do, in your own account, from day one | The repo lives with them |
| What documentation do we get? | Architecture, setup, deployment, as a deliverable | We will explain it if you need |
| Who else could maintain this? | Any competent developer in that stack | Only we know it |
| What happens when it breaks at 2am? | A named process and response time | Not discussed |
The maintenance question matters more on custom software than anywhere else, because nobody publishes patches for your specific application.
Standard e-commerce, content publishing, CRM, accounting. Custom here means paying several times more for something solved, and taking on maintenance you did not need.
If how the process works is still being argued internally, building software freezes an argument into code. Settle it on paper first; it is far cheaper.
Custom software needs dependency updates, security patches and someone accountable. Without that it ages faster and more dangerously than a platform, because no vendor is patching your specific application.
When your requirements involve genuine business logic, roles and permissions, or integration depth that platforms cannot reach. If a configured platform already does the job, custom is an expensive way to rebuild a solved problem.
Three to nine months for a genuine application, longer for a product. If someone quotes an application in four weeks, they are describing a platform configuration with a different label.
Something with a large developer pool so you can hire and get second opinions. The stack matters less than whether the next developer can pick it up, and whether it is documented well enough for them to.
Yes, unconditionally on final payment, including the repository and deployment documentation. Custom code you do not own is the worst of both worlds: bespoke work you paid for and still cannot leave.
A short, separately quoted piece of work producing a written specification: rules, roles, data model, integrations and edge cases. You own it whoever builds from it, which also lets you get genuinely comparable quotes.
Someone must. Dependencies need updating, security patches applying and hosting maintaining. Agree ownership before launch, because unmaintained custom code is more dangerous than an unmaintained platform.
Often. We audit first: stack and version, code quality, documentation and dependency state, then tell you honestly whether taking it over or rebuilding is better value. Sometimes it is genuinely rebuild.
Send us what you are trying to fix and we will tell you what it takes, what it costs, and whether we are the right people for it. If we are not, we will say so.