Every software project runs on two calendars. Ours, with sprints, staging builds and releases. And yours, with the decisions only you can make: which role may see what, which legacy system stays, who signs off the test data. When you commission custom software development, the proposal usually shows only the first calendar. I think the second one is the calendar a project runs late on.
I run delivery at CODT Technologies, the part between the signature and the handover. So next to every step below you will also find what we need from you.
Custom software development: the short answer
Custom software development at CODT Technologies costs $30,000–55,000 for a lean first release, delivered in 8–14 weeks, $55,000–110,000 for a product with several roles and real integrations in 12–20 weeks, and from $120,000 for a complex platform. The process has five steps: discovery sprint, foundation, core workflows, hardening, go-live with a 30-day warranty.
Indicative band, not a quote — the fixed number comes out of a paid discovery sprint and is credited against the build. Figures are in US dollars; Swiss and EU clients receive their quote in francs or euros from the same 2026 rate card.
The software development process in five steps: what you get and what we need
The table is the short version. The notes under it are the part worth talking through in a first conversation.
| Step | What you have at the end | What we need from you for it |
|---|---|---|
| 1. Discovery sprint (1–2 weeks) | Written scope, architecture, costed roadmap, "won't build" list; the fixed quote is written from these | Workshops with the people who will use the software, not only the people ordering it |
| 2. Foundation | Sign-in, roles, tenants, deployment pipeline, staging environment | Access to the systems being connected, and a decision on login (your own user management or your company's single sign-on) |
| 3. Core workflows | Every 14 days, a version on staging your people can operate | Real users who try each build, and someone allowed to say yes or no within a few days |
| 4. Hardening | Proof that the system holds under load, with wrong permissions, in failure cases and after a restore from backup | Realistic data volumes, and a decision on what is acceptable in the worst case |
| 5. Go-live and 30-day warranty | Production system, runbooks, source code handover | A date when people actually switch over, and a plan for running it afterwards |
A few words on the steps that get misjudged most often.
The discovery sprint costs $2,900–4,900 and is credited in full against the build. At the end, four things are on the table: the scope, in writing; the architecture; a roadmap with numbers attached; and the list of what we deliberately won't build. All four are yours, and the fixed quote is written from exactly these pages. That last list is the page I would read first. Without it, every idea mentioned in a workshop and never written down as out is still in play. And it comes back halfway through the build, when there is no document to point to.
The foundation is the phase where there is least for a client to see. Weeks go by and all there is to look at is a login screen. Underneath it, roles, tenant separation and the pipeline that will ship every later version are taking shape. That is why we still show something every two weeks in this phase, even when it is small. Cut corners here and it shows up in step four.
The core workflows run in two-week cycles, and each cycle ends with a build on staging that your own people can work with. Not a slide deck. A status report can sit at 80 percent for weeks. A staging build has no percentage: your dispatcher opens it, tries to do Tuesday's work in it, and within ten minutes we know where it is still wrong. No report tells us that, and no project manager would spot it either. That is not always a pleasant meeting, for either side. I still prefer it to six weeks of slides.
Hardening is the step most likely to get shortened once the date gets close. I wouldn't shorten it. A permission bug that lets one customer see records that aren't theirs stops being a bug after go-live. It becomes an incident.
After go-live there is a 30-day warranty. After that, a support plan; our smallest is $550 a month for 15 hours. Annual support typically runs at 15–20% of the original build cost. Whoever builds for you, ask for that number before the first sprint, in writing.
Custom software development cost in 2026
The number depends on three things: how many roles and integrations the software has, how reliable it has to be from day one, and whether a legacy system is being replaced alongside the new build. Our 2026 bands:
- Lean MVP: 2–3 engineers, 8–14 weeks, $30,000–55,000. One core journey, with standard components wherever your business doesn't depend on them, in front of real users early.
- Standard product: 3–4 engineers + delivery lead, 12–20 weeks, $55,000–110,000. Several roles, real integrations, an admin surface and the operational reporting a business runs on.
- Complex platform: 5+ engineers, multi-discipline, 20+ weeks, $120,000–250,000+. Multi-tenant SaaS, hardware or telephony in the loop, regulated data, or a migration running beside a live system.
A fourth thing moves only the date: how fast decisions get made on your side.
If you prefer to think in months: a typical team of 4 engineers plus a delivery lead costs $19,000–24,000 a month, and a working month is 160 hours with a 4-to-6 hour overlap with your business hours. The monthly rate for each role is public on our pricing page.
Indicative 2026 bands, not a quote. What moves the number is complexity — integrations, compliance, data migration and the reliability bar you need on day one. Every engagement is priced fixed and in writing after a paid discovery sprint, and the sprint is credited in full against the build.
Not in our price, and if another quote folds them in, ask what the markup is: cloud and licence fees, which AWS, Azure or GCP bill you directly or we pass through at cost with the invoice attached, and VAT. If you want to run your own numbers, our cost calculator breaks each building block down into engineer-weeks and the role behind them. For a web application with roles and reporting, the web-app article is the closer estimate. For an app in the stores, this one.
And before you commission custom software at all: if an off-the-shelf product covers most of your case and the rest isn't your core business, buy it. My colleague Anjan wrote up when custom software is the better choice.
Fixed price or time and material?
The question belongs in every first conversation. The answer depends on how settled your scope is.
Dedicated team. Named engineers reserved full-time for you, billed monthly at a flat rate. You own the backlog and set the priorities. Fits roadmaps longer than three months. Notice is 30 days for up to four engineers, 60 days for five or more, with no exit fee.
Time and material. Billed per hour worked, with a timesheet attached to every invoice, 40 hours a month minimum. Makes sense when the scope is still moving, or when you need a specialist alongside your own team.
Fixed scope. A fixed price against a signed specification, paid on milestones, priced from the same rates plus a risk buffer. Requires the paid discovery sprint first.
If your scope isn't settled yet, don't take a fixed price. Not from us either. A fixed price on an enquiry email contains a buffer for everything the vendor doesn't know yet. What they don't know still turns up during the build, as a discussion about whether it was in scope. After a discovery sprint, that discussion has a document both sides can point to: the signed scope, with the won't-build list next to it. In all three models the same rule applies: on payment, the code and every work product pass to you in full, 100% of the IP, with no per-seat licence.
How this went at Aviatize
Aviatize, a company based in Belgium, runs a platform for flight schools and flight operators. Before it, safety-critical things lived on paper: logbooks, certificates, maintenance dates. An expired certificate could keep an aircraft on the ground, and before every inspection by the regulator someone spent days rebuilding records by hand.
Discovery there ran for weeks: we looked at the workflows at twelve partner flight schools before a line of code was written, because EASA and FAA rules differ, and an operator flying under both had been maintaining the same data several times over. Go-live was then staggered, one regulator's jurisdiction at a time, with operator training and dispatcher onboarding.
Today more than 1,000 aircraft and crews run on the platform. Preparing for an audit takes four hours instead of three days. The full case study is in the portfolio.
What has to come from your side
This is the part hardly any quote contains. I would still settle it in the first conversation, because it decides whether the calendar holds.
One person who is allowed to decide. Not a committee that meets every few weeks. If we show a workflow on staging and wait three weeks for an answer, it isn't only that workflow that slips.
Real users from step three. The clerk, the dispatcher. Whoever will operate the software all day sees in ten minutes what nobody notices in a management sign-off.
Access and data, early. Every system we connect has its own credentials, and every one of them goes down at some point. The later we get them, the later we know what those systems can really do.
And a plan for running it. The code we hand over is finished; the world around it isn't. A library gets a security patch, a payment provider retires an API version, a browser changes a rule. Somebody has to own that. A plan is cheaper than an emergency.
The first step
Getting started costs nothing: a first workshop and a high-level estimate, usually back within three working days. Before we talk about your system, an NDA is signed; a DPA and standard contractual clauses are part of our standard paperwork. We staff standard roles within 2–3 weeks and specialists within 4. How we build custom software, from architecture to handover, is on our custom software development page. And if you are still weighing an in-house team, freelancers and a partner against each other, outsourcing vs in-house puts the three side by side.
Tell us what work the software should take off your people's hands.
FAQ
How long does custom software development take?
A lean first release takes 8–14 weeks with us, a standard product 12–20 weeks, a complex platform more than 20 weeks. Add a 1–2 week discovery sprint before and a 30-day warranty after. Two things outside our hands can stretch it: decisions that take a while, and access to legacy systems that arrives late.
Do I need a requirements document before I enquire?
No. One page is enough: who will use the software, what those people do today instead, and which systems have to be connected. The requirements document is produced in the discovery sprint, together with the architecture, the roadmap and the list of what is deliberately not built. It stays your property, whoever you build with.
Can I get custom software developed at a fixed price?
Yes, after the discovery sprint. The fixed price is calculated from a signed specification, at the same rates as a dedicated team plus a risk buffer, and paid on milestones. Without discovery, a fixed price is an estimate with a buffer in it, and you pay for the buffer either way.
Who owns the source code after the project?
You do. On payment, the source code, the runbooks and the tests from development pass to you: 100% of the IP, no per-seat licence, no lock-in. Another team, or your own, can keep the system running without us afterwards. That is what the handover in step five is for.
What does the software cost after launch?
Set aside 15–20% of the build cost per year: security patches, new library versions, monitoring, small changes. On a $60,000 build that is roughly $750–1,000 a month. Our support plans are fixed-price and start once the warranty ends; your cloud provider's bill comes on top, with no markup from us.
