Web applications
Multi-tenant SaaS and internal platforms with the unglamorous parts done properly: authentication, tenancy, audit, backups.
Next.js · TypeScript · Node.js or Python (FastAPI) · PostgreSQL
CUSTOM DEVELOPMENT
Custom software with a paper trail, from the first pull request.
Web and mobile applications, APIs and integrations, and legacy modernisation without a big-bang cutover. Next.js and TypeScript, Node.js and Python, React Native and Flutter, on AWS, Azure or Google Cloud, with every merge reviewed by a senior engineer.
How it works
How a legacy system is modernised without a big bang: six stages, two of which can stop it.
A new build runs the same rail from Carve onward, with nothing to retire: every pull request reviewed by a senior engineer, built once, promoted through the same gated pipeline the cloud line runs. Every stage leaves an artefact: a reconciliation report, a routing change, a runbook. That is what makes the migration auditable, and what a reviewer sees when they ask how the cutover was controlled.
- Map (Discovery). An inventory of modules, data and the dependencies between them. The seams are chosen before anything moves. Tools: Dependency map, Data ownership per module.
- Facade (API layer). A gateway goes in front of the legacy system so callers stop depending on its internals. Nothing behind it changes yet. Tools: API gateway, OpenAPI contract, Request logging.
- Carve (Rebuild). The first bounded module is rebuilt behind the facade, on the new stack, with its data migrated alongside and reconciled against the old. Tools: Next.js, TypeScript, Python, Migration scripts, Reconciliation report. Gate: Reconciliation must match before any traffic moves.
- Shift (Traffic). A share of traffic moves to the new module while the old one stays warm. The share grows as the error budget holds. Tools: Feature flags or weighted routing, Error budget. Gate: Rollback is a configuration change, tested first.
- Retire (Decommission). The legacy module is switched off once the new one has run clean for an agreed period, and its data path is closed. Tools: Runbook, Archive and access record.
- Repeat (Next seam). The same loop for the next module, until the legacy system is gone or only the parts worth keeping remain. Tools: One module per iteration, Weekly demo.
What we build
Five things we build, and what each one is built on.
Mobile applications
One codebase for iOS and Android, with native modules where the platform needs them.
React Native · Flutter · app-store release pipelines
APIs and integrations
Versioned APIs and partner integrations designed as contracts and documented before they are built.
OpenAPI · webhooks · idempotent retries · rate limits
Legacy modernisation
One bounded module at a time behind a facade, with a rollback path at every step and reconciliation before any traffic moves.
Strangler-fig migration · data reconciliation · traffic shifting
Product engineering pod
A senior pod embedded with your team, shipping in your repository and your pipeline.
Two to four engineers · your tools · a demo every week
How we work with you
Three shapes. Most builds start with the first.
- 018–12 weeks
MVP build
A validated idea taken to a first production release, with CI/CD, monitoring and documentation from the first week.
- 0216–24 weeks
Legacy modernisation
The seams mapped, a facade in front of the legacy system, and the first modules rebuilt and cut over with reconciliation at each step.
You leave with
The first modules live on the new platform, the migration tooling and the runbook to finish the rest.
- 0312 weeks and up
Product engineering pod
Senior engineers shipping in your repository, with a weekly demo and a code review trail.
You leave with
Velocity your team can see in its own pipeline.
Five phases, and the artefact your team holds at the end of each.
The full process- 01
Discovery & Strategy
1-2 weeks
Requirement specification and technical feasibility audit
Signed off by you, before engineering starts
- 02
Architecture & Design
2-3 weeks
Architecture diagram and high-fidelity prototypes, reviewed with your security team
Signed off by your security team
- 03
Agile Development
4-12 weeks
Production codebase with the code review trail and a working CI/CD pipeline
Signed off by a senior engineer, every PR
- 04
Quality Assurance
2-4 weeks
Coverage and QA report with performance benchmarks
Signed off by your QA and compliance teams
- 05
Launch & Evolution
Ongoing
Deployment telemetry and the post-launch support plan
Signed off by your team, every week
A build engagement runs 9-21 weeks to launch, then ongoing. Every phase ends with a named artefact and a named sign-off, under ISO/IEC 27001 and ISO 9001 controls.
Recent work on this line
Two engagements running on this line now.
ERP / Enterprise Software
Active engagementERP transformation programme for a UK-based consultancy
- United Kingdom
- ERP
- Programme delivery
Healthcare / Genomics
Active engagementGenomics-domain platform development for an Indian clinical genomics centre
- Clinical genomics
- Clinical workflow
- Platform
How we work
Built like a product company, shipped like one.
- 01
Audit-engineered by default
Every engagement runs under ISO/IEC 27001, ISO 9001, ISO/IEC 20000, and ISO/IEC 42001 controls. DPDP-aligned, with HIPAA / GDPR / RBI overlays available per project.
- 02
Founder-led delivery
Your discovery call is with a founder. The architecture review is with a senior engineer who stays on the project. No body-shop, no offshore handoff, no account-manager translation layer.
- 03
Bias to ship, not slide
We don't write demos that can't survive a Friday production deploy. Every milestone produces an artifact your team can use immediately: code, diagrams, telemetry.
Questions buyers ask
Straight answers, before the first call.
Which stack do you build on?
Next.js and TypeScript on the front, Node.js or Python (FastAPI) behind it, PostgreSQL by default, React Native or Flutter for mobile. Infrastructure as Terraform on AWS, Azure or Google Cloud. We recommend from this set because we can staff it with senior engineers; we say so when a brief needs something else.
Who owns the code?
You do, from the first commit. The repository is yours, the cloud account is yours, and the CI/CD pipeline runs in them. When the engagement ends there is nothing to hand over because nothing was ever held elsewhere.
How do you modernise a system we cannot switch off?
Strangler-fig, not rewrite. A facade goes in front of the legacy system so callers stop depending on its internals; one bounded module is rebuilt behind it with its data migrated and reconciled; a share of traffic moves across with a rollback that is a configuration change; the old module is retired once the new one has run clean. Then the next seam.
Can your engineers work inside our team and tools?
Yes. The product engineering pod ships in your repository, your issue tracker and your pipeline, and demos every week. No parallel process, no translation layer.
What does a senior review on every pull request actually mean?
No change reaches the main branch without a review by a senior engineer who is not its author, with the ticket, the test run and the approval linked in a tamper-evident log. It is the same code review trail the QA report and the ISO 27001 audit read.
Insights
From the blog.
Nothing filed under software engineering yet. These are the latest notes from the work.
Have a custom build in mind?
Book a 30-minute discovery call. We'll review the brief and sketch an architecture.
+91 912-195-7728Hyderabad, IndiaEvery brief gets a senior review. Reply within 1 business hour, 9 AM-7 PM IST.