Web products and internal platforms
Customer-facing products and the unglamorous internal tools that quietly decide whether a business scales.
Custom software development, with the controls visible the whole way.
Web and mobile products, internal platforms, APIs, and integrations, delivered with acceptance criteria agreed up front and demonstrations every week.
- Web products and internal platforms
- Mobile applications for iOS and Android
- APIs, workflows, and integrations
- Quality assurance and release engineering
- Documentation and source-code ownership
The uncomfortable part of commissioning software is the gap between paying and seeing. Months can pass in which the only evidence of progress is a status report written by the people being paid.
We close that gap with weekly demonstrations of working software, a backlog you can see and reorder, and time reporting you do not have to ask for. None of it is remarkable. It is simply what makes a delivery reviewable while it is still cheap to change.
Everything is written into a codebase you own from the first commit, with documentation and source code ownership yours by contract rather than by request.
What the engagement includes
Mobile applications
iOS and Android from one codebase where that fits, and closer to the metal where it does not, including the store submissions and the OS releases that arrive whether you planned for them or not.
APIs, workflows, and integrations
Connecting the systems you already run, including the ones nobody wants to touch.
Quality assurance
Automated tests where they earn their keep, and a human check on the paths that matter most.
Release engineering
A deployment anyone on the team can run, repeatably, without a ritual.
Documentation and ownership
Architecture decision records and runbooks, written alongside the code from the start.
Weekly demonstration
Working software, every week, not a slide about working software.
Whether this is the right fit
We would rather tell you now than three weeks in. If the right column describes you, say so on the call and we will point you somewhere better.
Best when
- The outcome is clear enough to write acceptance criteria for
- You want one team accountable for design and engineering together
- The product needs to be maintained after launch, not abandoned at it
- You value seeing progress weekly over a lower headline number
Not the right fit when
- Scope is still genuinely unsettled, in which case start with discovery
- The only criterion is lowest price, since we will not be it
- Nobody on your side can review and accept work at a weekly cadence
- You need a team of twenty starting next week
How it runs
Agree the outcome
What done means, in writing, including what is explicitly out of scope.
First useful delivery
Something small, real, and in production. It proves the working relationship before the big commitment.
Weekly cadence
Demonstration, backlog review, time report, and a decision about what comes next.
Release
To production, repeatably, with monitoring in place before anyone depends on it.
Hand over or continue
Documentation and access so you could take it in house tomorrow, whether or not you intend to.
How this is priced
A defined release with settled scope suits fixed price. A product that will change as you learn suits time and materials with a budget cap. Continuous work after launch usually moves to rolling monthly.
Where the work happens
We build on GMT+7, overlapping the European morning and the US East Coast evening. The weekly demonstration is booked in your working hours, not ours. Custom software development is usually bought on rate alone; the reason to buy it here is accountability instead: one named delivery owner, source code you own from the first commit, and a registered business you can check on the public tax register before you sign anything.
Before you ask on the call
Who owns the code?
You do, by contract, and it is committed from the first day rather than delivered at the end.
What if we do not like what you demonstrate?
That is what the weekly demonstration is for, and it is the cheapest moment to say so. Work that misses the agreed acceptance criteria is our cost to correct. Work that meets them but is not what you now want becomes the next item in the backlog, reprioritised against everything else. Either way you find out in a week rather than at a handover.
What stack do you work in?
Mainstream web, mobile, and backend technologies chosen for the problem and for who will maintain it, not for what is currently fashionable. On mobile that usually means one cross-platform codebase serving iOS and Android, dropping into native code where a platform genuinely needs it.
Can you work with our existing team?
Yes. If you mainly need capacity rather than a delivery owner, contract engineering is the better shaped service.
If this is not quite the shape of it
The engagements next to this one, and the reason you might want them instead. All five are in the Services menu at the top of the page.
Bring the product question you need answered next.
Thirty minutes by video with Tai. We will clarify the problem, your current stage, the likely delivery path, and whether TPSolutions is a sensible fit.
Half-formed requirements are fine. Sharpening them is part of the job.