
Our cases
Clients about us
Custom software development
Requirements, specification, build, and operations. Source code and usage rights stay with you.
What custom software is

Custom software is a system built for one client instead of licensed from a catalogue. Work starts with a requirements analysis and a written specification, not with a module you then work around. Packaged software models a market. Custom software models your process: roles, approvals, interfaces, and the data that has to stay with you. WTT Solutions delivers that as a fixed price when the scope is written, or as time and material when it is still moving.
Having custom software built means you receive the source code, the usage rights, and documentation another team can continue. Operations and maintenance are a separate contract, with an SLA and hosting in the EU. Where personal data is involved we sign a processing agreement under GDPR Article 28. Back to the English homepage. If several customers must share one product and stay isolated, that work belongs on platform development.
When custom software pays off, and when it does not
Custom software pays off when packaged software breaks the process, or when the licence over five years costs more than the build. It does not pay off when a product already fits, or when nobody on your side can approve a requirement.
The package forces the workflow
If approvals, roles, or reports only work through side spreadsheets, the licence fee is no longer the cost. Custom software is the shorter path, because the specification describes the process you actually run.
The licence overtakes the build
An internal portal billed per seat and per module often exceeds a fixed price for the same scope within a few years. We put both numbers in the requirements analysis before anyone signs.
Only a form is missing
If packaged software already carries the core and you only need a field or an export, we do not build a new system. A small change or the existing configuration is enough. Custom software for that remainder is spend without a return.
No specification without a decision
Without a person who can approve requirements, the specification becomes a wish list. We stop before the build. Time and material without that owner burns weeks. A fixed price without them gets renegotiated.
Examples from our projects
Connect with students for live 1-on-1 college insights and tours

EXPERTISE
Education
TECHNOLOGIES

What the custom software engagement includes
Requirements analysis and specification
We write goals, roles, interfaces, and acceptance criteria before production code. That specification is what a fixed price or a time-and-material plan stands on. Planning duration: two to four weeks for the analysis, two to four more for the specification, often four to seven weeks together.
Requirements analysis and specification
We write goals, roles, interfaces, and acceptance criteria before production code. That specification is what a fixed price or a time-and-material plan stands on. Planning duration: two to four weeks for the analysis, two to four more for the specification, often four to seven weeks together.
Delivery by an external team
If you keep the decisions and hand over the build, delivery runs as software development outsourcing. Every two weeks you see working software, not a report about software. The source code sits in the agreed repository, not only on our machines.
A product for several tenants
Once several customers use the same software and must stay apart, this is no longer a single custom system. It is platform development. We say so during analysis, so the fixed price and the architecture describe the same scope.
Extra people on your team
If the architecture stays with you and capacity does not, we add people through IT staff augmentation. That is not a second project and not a lock-in: they work in your repository, under your lead, on time and material.
GDPR and hosting in the EU
If the system holds personal data, we sign a processing agreement under GDPR Article 28. Hosting in the EU is the default, not a footnote fee. We describe what the regulation asks of you as controller. We do not promise that an authority will approve the system.
Maintenance and SLA
After handover, maintenance is its own contract: incidents, small fixes, dependencies. The SLA names response times, not new features. New features are a new specification or time and material. For an internal portal, monthly planning ranges are often €1,500–€3,000.
Eight steps to a finished system
Each step has a duration in weeks and a result you can review. The ranges are for a bounded business process, not for an unnamed program.
Requirements analysis
We collect goals, roles, data, and the points where packaged software fails today. The result is a decision: build, buy, or stop. Duration: 2–3 weeks.
OutputGoals, roles, interfaces
Requirements analysis
We collect goals, roles, data, and the points where packaged software fails today. The result is a decision: build, buy, or stop. Duration: 2–3 weeks.
OutputGoals, roles, interfaces
Specification
The specification names scope, acceptance criteria, and what will not be built. Without that boundary there is no fixed price. Duration: 2–4 weeks.
OutputSpecification with acceptance criteria
Architecture and proposal
We fix the cut, data stores, and hosting in the EU, then propose a fixed price or time and material. Wording on source code and usage rights goes to legal before signature. Duration: 1–2 weeks.
OutputFixed price or time and material
Prototype
A clickable path through the main screens before the build widens. Changes go back into the specification. They are not quietly added. Duration: 2–3 weeks.
OutputClickable flow
Build
Work in two-week cycles. You see software, not slides. An internal portal with four roles and two interfaces often takes 8–16 weeks here. Larger work takes longer, and the proposal says so.
OutputWorking increments
Test and acceptance
We test against the specification, not against a general impression. Open items have an owner and a date. Duration: 2–4 weeks.
OutputAcceptance record
Handover
Source code, access, build, and a short operations note come to you. Your team or another supplier can continue from there. Duration: 1–2 weeks.
OutputSource code and documentation
Maintenance
SLA, hosting in the EU, and small fixes. New topics are estimated again. They are not folded into maintenance. Maintenance has no fixed end date. The monthly price does have a range.
OutputSLA and operations
Custom software and packaged software compared
The same question in one table: process, rights to the source code, licence, interfaces, hosting in the EU, and maintenance. Packaged software wins when it already matches the process.
- Advantage
- Trade-off
- Not met
What custom software costs
Ranges for planning, not quotes. Worked example for an internal portal with four roles and two interfaces: requirements analysis and specification in 4 weeks for €12,000–€18,000, build in 16 weeks for €90,000–€130,000, then maintenance at €1,800–€2,800 per month. A fixed price only sits on a written specification. Time and material when the scope is still moving. Clinical products and their rules belong on the healthcare pages, not in these ranges.
Requirements analysis
€12–18k
2–4 weeks
- Goals, roles, interfaces
- Specification with boundaries
- Fixed price or time and material
- Note on GDPR and hosting
- No obligation to build with us
Internal portal
€80–140k
14–18 weeks
- Specification and prototype
- Four roles, two interfaces
- Build in two-week cycles
- Source-code handover
- EU hosting prepared
Several processes
€160–280k
6–12 months
- More than one business process
- More than two interfaces
- Separate acceptance points
- Maintenance and SLA from go-live
- GDPR Article 28 processing agreement
What clients say
INDUSTRY RECOGNITION

Luklabs
Acting CEO
The team is smart, creative, nice, calm, and professional, and they are problem solvers.
WTT Solutions paid attention to details. Most of their first iterations were very close to our intended designs. Consequentially, we didn’t have to do a ton of revisions in the QA phase.
I greatly enjoyed working with them.

Build in-house or hire a supplier
The question is not which word sits in the contract. It is where the architecture, the capacity, and the specification sit. In-house is right when your team already runs the stack and has time. A supplier is right when the business decision stays with you and the build would otherwise stall. Both at once is staff augmentation: your lead, extra people.
In-house when the team has time
You know the data and the legacy. Custom software inside your team pays off when the same people will maintain it. If only the calendar is missing, the work becomes a side project.
A supplier when capacity is missing
We deliver the analysis, the specification, and the build, fixed price or time and material. Source code and usage rights stay with you. Business approval stays with you.
Mixed, through staff augmentation
Architecture and repository stay with you. We add people on time and material. That is IT staff augmentation, not a second product and not a quiet transfer of ownership.
Fixed price when the specification is done
A fixed price covers the written scope, including the named interfaces and acceptance. Anything added later is a change, not silent maintenance.
Time and material when scope is open
While roles or interfaces are still moving, a fixed price is a number without cover. Time and material on a two-week cycle shows the spend before it becomes a surprise.
Typical custom software we build
01
Internal business portal
Four roles, two interfaces, approvals no package provides. The worked example above: 14–18 weeks, €80,000–€140,000 as a planning range.
02
A bridge between two systems
The data already lives somewhere and only the path is missing. The specification names fields, failure cases, and who is told when a run stops. Often 6–10 weeks after analysis.
03
Replacing part of a package
Only the part the licence no longer carries. We leave the rest. The analysis says which part that is before the build starts.
04
A portal for customers
Sign-in, documents, status. Hosting in the EU and, once personal data is involved, a GDPR Article 28 processing agreement. Not a catalogue product with your logo.
05
Reports on data you already have
Reports that today live in spreadsheets. The source system stays in charge. We build the view, not a second version of the truth beside it.
06
A published project
One public example is the work with Luklabs: early drafts sat close to the intended design, and the review cycle stayed short. The reference is in the quotes on this page, not as an invented metric.

Source code, usage rights, and maintenance
Three things the contract has to state before the build starts: who owns the source code, which usage rights transfer, and what maintenance costs after acceptance. Copyright wording is agreed with legal. Open-source libraries stay under their own licence and are listed in the repository.
Source code
Repository, build, and history pass to the client at acceptance.
Usage rights
The clause is agreed with legal before the contract is signed.
Maintenance
A separate contract after handover, apart from new features.
SLA
Response times for incidents, not quiet feature requests.
GDPR Article 28
A processing agreement when we handle personal data.
Hosting in the EU
EU operations as the default, written in the specification.
Access
Roles and logs, as the GDPR expects of the controller. No promise of an authority sign-off.
Documentation
Short, and enough for another team to continue the source code.
Technology we use to build custom software



