Live · your codebase, your cloud account
Custom software builds, delivered end to end.
We take a system from the first requirements session to production, and we support it after release. Java, C# / .NET, TypeScript on the front end, deployed into your own cloud account. This is also the line we are folding into Etheria, so the rest of this page says plainly what that means for a project starting now.
What we build
Business systems a company runs on rather than sells: internal platforms, customer-facing web applications, integrations between systems that were never designed to talk to each other, document handling and workflow automation. On most of these projects the application code is not where the work is. The work is in the integration surface and in the rules nobody ever wrote down.
Backend
- Java
- C# / .NET
Web
- TypeScript
- Next.js
- React
- Angular
Infrastructure
- AWS
- Your own cloud account
Deployed into your AWS account, or whichever cloud account you already run in. We work in your accounts and your repositories, not ours.
How a build engagement runs
This is the same way we run analysis inside someone else's delivery team, applied to our own build. The specification is the deliverable; the code is what comes out of it.
Stage 1
Scoping call, then a written scope
Thirty minutes on what the system has to do, what it has to talk to, and what 'done' means for the first release. You get back a written summary of scope and the three or four parts we think carry the most risk, whether or not you hire us.
Stage 2
Requirements and acceptance criteria, before any code
Every work item carries what it must do, what it must reject, and how you'll know it works. Edge cases get written down at this stage instead of discovered in UAT. This is the part of a build most suppliers compress and it's the part we sell for a living.
Stage 3
Design and integration contracts
Screens and flows agreed before development starts. API contracts and data flows specified for anything crossing a system boundary — including what happens when the other side is down, slow, or returns something the documentation didn't mention.
Stage 4
Build and test in sprints, with a demo you can attend
Every change goes through pull request review and automated tests before it merges. At the end of each sprint you see the software running rather than a status deck.
Stage 5
Release and handover
Release into your environment, with a runbook, the specifications, the test record and the repository. If you later take the system in-house or to another supplier, everything they need already exists in writing.
We're winding this line down. Here's what that commits us to.
Etheria is the pipeline we're building to do this work. It's in Beta now, with general availability targeted for Autumn 2026. When it's ready it becomes the first thing we quote. Classic builds don't stop existing at that point — they stop being the default.
That leaves one question worth settling before you sign anything: what happens to a project that is halfway delivered when the switch happens. Here is the commitment.
A project quoted on this model is delivered on this model.
Start to finish, on the terms in your contract. Etheria reaching general availability does not migrate your project mid-delivery and does not put you in a re-planning exercise you didn't ask for.
If moving your project onto Etheria would genuinely help you, we'll ask.
It arrives as a change request with a reason attached. You can decline it, declining costs you nothing, and the original terms stand.
Support after release runs on your contract, not on our roadmap.
The code, the specifications and the repository are yours throughout, on either model.
Does it mean my project gets the B team?
The people who scope your build are the people who deliver it, and that doesn't change. Etheria isn't a separate department competing for attention — it's the same delivery process with the mechanical parts of it automated, built by the people who got tired of doing them by hand.
Am I buying a system built on something you're about to abandon?
No. What's changing is how we run the delivery, not what we deliver into. Your system is Java or .NET or TypeScript, in your repository, on your cloud account, with your CI. None of that is Etheria, and none of it depends on us still being here. If you took the codebase to another supplier next year, they'd find a normal project.
There is a version of this where you should wait for Etheria rather than start a classic build. For some projects that is the right call, and we'd rather say so than take the work. The criteria are in the next section.
Which model fits your project
Both are sold by the same people, so nobody here gets paid more for pushing you one way. These are the criteria we actually use when we decide what to quote.
A classic build is the right call when
- The work is deep integration into systems that were never designed to talk to each other, where most of the effort sits in the contract between them rather than in application code.
- The scope is fixed by a regulator or by a contract and will not move, so a fixed price is worth more to you than flexibility.
- There is a legacy codebase with undocumented conventions and behaviour other systems quietly depend on. That needs a person reading it, slowly.
- A third-party runner cannot be given repository access in your environment, or the security review to allow it would run longer than the build.
- AI-assisted code is out of scope under your current policy.
Start with Etheria, or wait for it, when
- You have more approved backlog than engineering capacity, and hiring won't close the gap this year.
- It's a modern web application with a clean repository and a test suite we can run.
- You want the delivery record — requirement to change to test result to the name that approved it — as an output of the process rather than a document produced for a review.
- You can give us a bounded first scope and a named person on your side who can approve work items without convening a committee.
- Your project starts after general availability in Autumn 2026 and fits the criteria above. Starting there costs less than starting classic and migrating later.
What we can and can't show you
The client names elsewhere on this site — Universal Music Group (UK), Raiffeisen Bank Romania, UNFCCC (Germany), LSEG (USA), Finstro (Australia), ING Hubs Romania, Alior Bank, DCA Ventures — are Technical Business Analysis engagements. We were the analysis layer on those programmes, working through primes including NTT DATA, Qualitance / ALTEN, Investigo / Definia and E-Resourcing UK. Other people wrote the code. They are not build references and we won't present them as any.
What we can show you is how those engagements were run: acceptance criteria written before code, a traceability record assembled as work moved, and a named approver on every change. The same three apply to a build here, and the dated record is at /work. Then our own builds — this website and the Etheria pipeline, both built by us, both things you can open right now and form your own view about.
We don't have published client build references.
Where we've deliveredHow a build is priced and contracted
Fixed scope, fixed price
Quoted after the specification stage, not before it. Quoting a fixed price against an unwritten specification is how both sides end up arguing about change requests in month two, so we don't do it.
Time and materials, dedicated squad
Where the scope will move, or where you'd rather steer it sprint by sprint. You get the same review gates either way; what changes is who carries the estimating risk.
Specification only
We run the analysis stage and hand you a buildable specification with acceptance criteria and integration contracts. Your team or another supplier builds it. This is our main business rather than a consolation prize, and it's often the right first step even when we do end up doing the build.
- IP
- You own the source code, the specifications and the repository.
- Contracting
- Direct with Theta One Digiplex S.R.L., or as a subcontractor under your existing prime. We've delivered inside enterprises in that model before.
Common questions
Tell us what you're building.
Thirty minutes, no deck. Bring what the system has to do and what it has to talk to. You'll leave with a written summary of scope and the three or four parts we think carry the most risk, whether or not you hire us.