Types of custom software development, reframed as a decision
There is no single type of custom software to pick. First choose your route to software, then, only if a real business driver forces a build, budget it honestly. Two tools on this page let you self-select your route and see your own numbers before you talk to a vendor.
Which way should you actually get your software?#
Search for "types of custom software development" and you get a glossary: web apps, mobile apps, enterprise systems, SaaS, and so on. That list answers a question you are not really asking. As the person who signs the cheque, your question is simpler and harder. Which way should I get this software, and what will it truly cost me over the next three years?
This is written for a founder or operator at a company past its first product, weighing a first serious custom build against a stack of subscriptions that keeps growing. The better frame is not a type, it is a route. There are four, from cheapest and fastest to most expensive and most yours. The decision tree below is the whole argument on one page. So read it top to bottom, then use the route finder under it to place your own project.
Answer four plain questions. Then the finder places your project on one of the four routes, with the reasoning spelled out and an honest note on why it did not pick the other three. Nothing here is captured or sent anywhere; it runs entirely in your browser.
Your route
Configure a platform
The middle path, no bespoke code
A product gets you most of the way but needs real setup, fields, and rules. Configure a platform (low-code or a configurable SaaS) before anyone writes bespoke code. It is the middle path most teams skip straight past.
Why not the other three
- Not buy: the product does not fit as-is, so someone has to shape it to your process.
- Not extend: the work is setup and rules, not deep wiring into systems you own.
- Not build: writing bespoke code for something a platform configures is over-buying.
Here are the same four routes side by side, so you can cross-check the finder against the exact trade-offs a buyer weighs.
| Route | Cost to start | Time to live | Control you keep | Fit to your process | Best for |
|---|---|---|---|---|---|
| Buy off-the-shelf | Cost to startLowest (subscription) | Time to liveDays to weeks | Control you keepLow | Fit to your processWhatever the product offers | Best forA solved, common need where you do not differentiate |
| Configure a platform | Cost to startLow to medium | Time to liveWeeks | Control you keepMedium | Fit to your processGood, within the platform limits | Best forA near-fit product that needs your fields, rules, and workflow |
| Extend and integrate | Cost to startMedium | Time to liveWeeks to months | Control you keepMedium to high | Fit to your processHigh at the seams you build | Best forSystems you already run that need to work together |
| Build fully custom | Cost to startHighest (first release) | Time to liveMonths | Control you keepFull | Fit to your processExact | Best forCore, differentiating software you must own |
Buy off-the-shelf#
If a product already does most of what you need and this is not where you win customers, buy it. This is the honest default for most business needs. Every hour you do not spend building is an hour spent on the work only you can do. The cost is a predictable subscription and the time to live is days. In return, you bend to the product rather than the product bending to you.
Configure a platform#
The middle path most teams skip straight past. A configurable platform or low-code tool gets you a product that is shaped to your fields, rules, and workflow without anyone writing bespoke code. Think a CRM molded to your sales stages, or a commerce platform themed and wired to your catalog. You keep more control than a raw purchase and pay far less than a build. The limit is real: when your process needs something the platform cannot express, you have hit the edge of this route and the next two begin.
Extend and integrate what you own#
The most overlooked route. You already run an ERP, a CRM, a billing system, and a data warehouse, and most of your pain is that they do not talk to each other. The answer is rarely a new platform. It is a thin layer of custom software that connects what you own and builds only the missing piece. You get the exact behavior you need at the seams that matter, without paying to rebuild systems that already hold your data and already work.
Build fully custom#
The route the rest of this page pressure-tests. A full custom build means you own the whole of it: the data model, the behavior, the roadmap. It is the most expensive route to start and the most yours to keep. Reach for it only when a real business driver forces it, which is exactly the next section. If you land here in the finder, treat it as a hypothesis to test with the budget tool, not a conclusion.
When custom is the right call: the four business drivers#
Custom is not justified by a technology, it is justified by a business driver. There are four. If none of them is clearly true, a build is usually the wrong route and the money proves it. If one is strongly true, a build can be the only honest option even though it costs more. First, feel the core trade the whole decision turns on: how fast you get working software.
~2 weeks
Buy off-the-shelf
~16 weeks
Build fully custom
Speed is the buyer's advantage, so a build has to earn its months back through differentiation, integration, scale economics, or control. If it cannot, buy and move on.
Show data table
| Option | weeks to a usable first version |
|---|---|
| Buy off-the-shelf | ~2 weeks |
| Build fully custom | ~16 weeks |
Differentiation you cannot buy#
If the software is something your customers notice and choose you for, you cannot buy it, because anything you can buy your competitors can buy too. A logistics firm whose routing engine is faster than the market, or a lender whose underwriting model is its edge, cannot rent that advantage. This is the strongest driver, and it is the one the route finder weights most heavily. Be honest about it though. An internal tool that saves your team time is valuable, but it is rarely a differentiator customers can feel.
Integration too deep to bolt on#
Sometimes the value is entirely in the wiring. Sometimes a workflow has to reach across your order system, your inventory, your finance stack, and a partner API in real time. In that case, no single product sits in the middle of all of it. A custom layer that owns those connections can be worth building even when every individual piece already exists. This is the driver that points to extend rather than a full ground-up build, and the finder respects that distinction.
Scale economics that make per-seat pricing hurt#
Per-seat subscriptions are cheap at ten seats and painful at two thousand. A custom build is a mostly fixed cost, while a subscription grows with every seat. As a result, there is a break-even point where owning the software becomes cheaper than renting it. Below that point, renting wins and building is vanity. Above it, the subscription quietly becomes one of your largest line items. The estimator below computes that crossover for your own numbers, so scale becomes a calculation rather than a hunch.
Compliance and control you must own#
You may have to own the data, the audit trail, or the deployment for regulatory or contractual reasons. When that is true, a vendor you cannot fully bind is a risk rather than a convenience. Certain data-residency, healthcare, and financial requirements make control a hard requirement rather than a preference. When that is genuinely the case, the added cost of a build buys you something a subscription cannot sell: it stays in your hands.
What a custom build really costs#
Most guides stop at "it depends," which is true and useless. Here is a defensible way to size it. A first release has a base cost for standing the software up. On top of that sits a cost per core screen or module, and a cost per integration into a system you already run. Then comes an annual run-rate to host, maintain, and improve it, typically 15 to 25 percent of the build per year. That run-rate is where naive budgets break: they price the build and forget the years. The discipline of pricing the whole life, not just the launch, is what Gartner calls total cost of ownership. In the end, it is the number that actually decides buy versus build.
The break-even against a subscription is the other half of the honest answer. Take a public per-seat price, for instance the mid-tier seat pricing on a tool like Slack. Multiply it by your seats and by 36 months. Then compare that to the three-year cost of owning the build. The estimator does exactly this. Set your route and scope and read the line-by-line math, the timeline, and the point where custom starts to win.
First release, line by line
- Base build setup
- $60,000
- 8 modules × $6,000
- $48,000
- 3 integrations × $8,000
- $24,000
- First release range
- $112,000 to $165,000
- Run-rate (20% / yr)
- $26,000/yr
- First release timeline
- 20 to 30 weeks
3-year total cost of ownership
At 120 seats, the subscription is cheaper over three years. Custom only starts to win past about 208 seats at this scope. If you are not near that, buy or configure and revisit later.
Illustrative planning model, not a quote. Ranges follow the first-release and run-rate bands in this guide; your real numbers move with team, region, and scope. Use it to sanity-check a vendor, then get a real estimate.
The chart below is that same model frozen at one scope: eight core modules and three integrations. As a result, you can see the cost ladder across the four routes without touching a slider. It is also the no-JavaScript version of the estimator above.
Show data table
| Item | Three-year cost of ownership |
|---|---|
| Buy | 25,000 USD |
| Configure | 77,000 USD |
| Extend | 128,000 USD |
| Build | 210,000 USD |
Each route up the ladder buys more control and fit for more money. The question is never which number is smallest, it is which route your business driver and your scale actually justify.
The nine types of custom software development, mapped to a route#
The classic "types of custom software development" list is not wrong, it is just organised around technology instead of decisions. So here are the nine you will see everywhere. Each one is mapped back to the route it usually means, and to the business driver that would justify building it rather than buying it. Read the type you came for, then follow it across to the decision it really represents.
| Type | What it is | Route it usually means | The driver that justifies building it |
|---|---|---|---|
| Web application development | What it isBrowser-based software for customers or staff | Route it usually meansConfigure, then build if core | The driver that justifies building itDifferentiation, when the app is the product |
| Mobile application development | What it isiOS and Android apps | Route it usually meansBuild, or extend an existing backend | The driver that justifies building itDifferentiation and reach your customers expect |
| Enterprise software (ERP, CRM) | What it isSystems that run core operations | Route it usually meansBuy or configure first, extend second | The driver that justifies building itIntegration and control, rarely a ground-up build |
| SaaS product development | What it isMulti-tenant software you sell to others | Route it usually meansBuild | The driver that justifies building itDifferentiation, because the software is the business |
| E-commerce software | What it isStorefronts, checkout, catalog, fulfillment | Route it usually meansConfigure a platform, extend at the edges | The driver that justifies building itIntegration and scale economics at high volume |
| Software integration and APIs | What it isConnecting systems you already run | Route it usually meansExtend and integrate | The driver that justifies building itIntegration too deep to bolt on |
| Cloud and platform engineering | What it isThe runtime, delivery, and scaling layer | Route it usually meansExtend what you own | The driver that justifies building itScale economics and control |
| AI and data software | What it isModels, pipelines, and decision systems | Route it usually meansBuild or extend, on top of bought models | The driver that justifies building itDifferentiation, when the model is your edge |
| Legacy modernization | What it isReplacing or wrapping aging systems | Route it usually meansExtend first, rebuild only the core | The driver that justifies building itControl and integration, almost never a full rewrite |
Notice how few of the nine point to a full build as the default. Most are a buy, a configure, or an extend, and turn into a build only when one of the four drivers is genuinely present. That is the entire point of leading with the route instead of the type.
If your route does land on a build, it helps to see what one actually looks like below the surface before you fund it. So here are two worked examples from our own software engineers, worth handing to whoever will build yours. First, how we render a web application at the edge to cut load time and hosting cost. Then, how we turn a web app into an installable mobile experience without paying for a separate native build. Both sit inside the "web application" and "mobile application" rows above.
When not to build custom#
The most valuable advice in a guide like this is the part that tells you to stop. Roughly two-thirds of software projects come in late, over budget, or short of their goals, a pattern the Standish Group has tracked in its CHAOS research for decades. A build is where most of that risk lives, so the honest default is to avoid one unless a driver forces it.
How to choose, in one paragraph#
Start from the need, not the technology. Run it through the route finder to see whether you should buy, configure, extend, or build. If it lands on build, name the driver out loud, then open the estimator and confirm the three-year math actually favors owning it. Most businesses end up with a portfolio. In practice, that means bought tools for the common work, a configured platform or two, a few custom integrations at the seams, and one genuinely custom system where they compete. If you want a second opinion on where your project sits, a short discovery engagement is the cheapest way to pressure-test a build before you commit. Because it is a small, fixed step, it is also how we scope custom software engineering, systems integration, and a first production release in practice. You can also see the pattern in an anonymized Scandinavian rental-services platform we modernized for scale and still run today.