How does custom software really get built?
In short
Building custom software is a process that moves in stages, not a series of random decisions. The client takes part in every phase: from defining the business problem, through validating the concept, to testing and signing off each milestone. The more regular the client’s feedback, the fewer surprises at the end of the project. Milestones let both sides check that the solution really matches the original idea — and that saves money, time and frustration.
Introduction
Picture a conversation in an office:
“We want a system that automates our sales reporting. Is that possible?”
The team replies: “Sure, give us two weeks.”
Two weeks later the system is ready. But when you test it, it turns out that:
- Reports are only generated for the last day of the month, but you need a date range
- Data from marketing campaigns is not included
- The system does not connect to your CRM
- Data does not update automatically and has to be imported by hand
“This isn’t what I wanted,” you say, disappointed. “But fixing it will cost more and take more weeks.”
The conflict does not come from laziness or bad faith. It is simple, unforgiving arithmetic: an idea that exists only in your head is not yet a specification that developers can build.
A good software development process is not bureaucracy that adds time to a project. It is an investment that protects your budget, your deadline and your vision. It shows exactly where you are, which decisions need to be made and what is happening under the hood before everything reaches you as a working system.
In this article we explain what that collaboration looks like, step by step. You will see that the best software is not the result of an idea colliding with technical stubbornness, but the fruit of regular conversations, tests and shared decisions.
Stage 1: The vision and the business problem
Before the first line of code is written, simpler questions need answers: why write it at all?
The team has to understand:
- What specific business problem the system should solve — not “we want an app” but “I lose 8 hours a week…”
- Who will use it — team leads, IT specialists…
- What business result it should bring — saving time…
- What your constraints are — budget, deadline, infrastructure…
Once these are clear, both sides know what to focus on.
Stage 2: The first meeting and discovery workshops
We begin with discovery workshops — a session in which we analyse the processes in your company together, get to know the users and map the project’s constraints and goals.
A well-run discovery session covers questions about:
- Business processes
- Users and their roles
- Data and where it comes from
- Integrations
- Security and permissions
- Regulations and compliance
- Goals and success metrics
Stage 3: Structuring the requirements
After discovery you have the big picture. Now it has to be broken down into parts.
The team translates your vision into precise project requirements. This is where a general idea becomes a set of concrete, unambiguous and testable assumptions.
Stage 4: Priorities and the scope of the first version
The first version should solve the main business problem.
EXAMPLE: for the insurance industry, the project needed 6–12 months. But the first version could cover just the insurance calculator and quote generation.
What do other delivery timelines look like?
- A simple online shop: 4–8 weeks
- A system of medium complexity: 8–12 weeks
- A complex custom application: 12–16 weeks
Stage 5: The roadmap and milestones
The roadmap is the plan of work stages. Each stage is a milestone.
What is a milestone? A point at which something concrete is ready to be checked: an interface, an integration, a permissions system.
EXAMPLE from the railway project: weeks 1–2 prototype, 3–4 backend, 5–6 data import, 7 testing, 8 acceptance, 9 fixes.
Stage 6: Designing the solution
Before developers start writing code, someone has to design how it will work.
This covers interface mock-ups, user flows, the technical architecture, integrations and prototypes.
Stage 7: Implementation and regular demos
Day to day, work on the code, the database or the server configuration happens behind the scenes. To give you full control over the project, we hold a presentation (demo) every two weeks. In those meetings you assess progress as it happens and we check the direction of the work together.
Stage 8: Your tasks during delivery
You need to: appoint a decision-maker, answer questions, test the versions, give concrete feedback and sign off stages.
No answer is also a decision — and it can affect the schedule.
Stage 9: Testing and user acceptance
There is a difference between “it has no bugs” and “it does what I need”.
You run the user acceptance tests (UAT) — you work with the system for real.
Stage 10: Fixes and final acceptance
New ideas and corrections almost always come up while software is being built. That is completely natural! But to keep the project within budget and stop it stretching on forever, we put every request into one of three drawers:
- Bug: the system does not work according to the specification agreed in the workshops (for example, a button was supposed to send an e-mail and does not). We fix it as part of the original agreement.
- Change request: an existing feature is modified in a way other than originally planned (for example, instead of a plain sign-up form we want Google sign-in).
- New idea: an entirely new feature that goes beyond the project’s original scope (for example, we want to add a customer loyalty module).
Stage 11: Handing over the software
What gets handed over: a working system, access credentials, documentation, the source code, instructions and operational know-how.
Stage 12: The acceptance report and documents
The day the software is ready to go live is a big moment. But we do not leave you alone with the new technology. Handover is a complete process, in which you receive a starter pack that makes the new tool comfortable to use:
- A working system — fully configured, tested and ready to serve your customers or staff.
- All the access you need — administrator accounts and access to servers, databases and integrated external services.
- Documentation and operational know-how — simple user instructions, plus onboarding for your team so that you feel confident in the new environment from day one.
- Source code (depending on the model) — if we build a custom system for you, we transfer the economic copyright and the source code to you. If you use our software under a licence or SaaS model, the code stays with us, so that we can keep it updated, developed and secure.
Stage 13: Development after launch
Handing over the first version is not always the end. The system can keep growing as new needs appear.
The cost of late feedback
If a whole project runs in silence for three months, there will be problems at the end.
The effect on time: a change after 2 weeks adds 1–2 days; a change after 12 weeks adds 1–2 weeks.
Why: differences in interpretation set in, changes get more expensive, the risk grows and the team cannot adapt.
Who is responsible for what
| Area | Digital Templars’ responsibility | Client’s responsibility |
|---|---|---|
| Defining the business problem | Asking, analysing | Defining and communicating |
| Functional requirements | Structuring, formalising | Verifying, answering |
| Acceptance criteria | Proposing | Approving |
| Technical design | 100% | — |
| Programming | 100% | — |
| Technical testing | 100% | — |
| User acceptance testing (UAT) | Moderating, supporting | Carrying out, verifying |
| Feedback | Collecting, documenting | Providing |
| Data security | Architecture, encryption | Procedures, permissions |
| Support after launch | Providing | Reporting problems |
FAQ — frequently asked questions
1. How long does it take to build software?
It depends on the scope. Typical timelines: a simple system 4–8 weeks, a medium system 12–16 weeks, a complex system 6–12 months, a very large one 12+ months.
2. How often should progress be checked?
Every two weeks is a solid standard — each milestone is a new version to test.
3. Who is responsible for the requirements?
It is a shared responsibility. You know what problem the system has to solve. The team helps turn that into formal requirements.
4. What happens if I change my mind?
Changes are normal. What matters is saying so early. Small ones can be folded into work already under way.
5. What is the difference between a bug and a change of scope?
A bug — the system does not do what it should. A change of scope — something new that was not in the plan.
6. When is the acceptance report signed?
Once the system has passed acceptance testing and has no critical bugs.
7. Which documents are signed?
Three: the contract for the work, an NDA (confidentiality) and the acceptance report.
8. Do I need technical knowledge?
No. You need to know how you work and which problems you want to solve.
9. What do I get at the end?
A working system, access credentials, documentation, the source code, instructions and technical support.
Summary
The best software is not built in silence. It is built when the client’s business knowledge meets the team’s technical experience.
Custom software is a process — orderly, transparent and with a clear split of responsibilities.
Ready for the next step?
If you are considering custom software for your company, we invite you to a free conversation about your project.
It will not be a sales call. It is a session in which we work out your business problem together.
Book a free consultation or send us a message if you would like to talk about your project.