Two things, done properly.
A deliberately narrow practice. We would rather be the obvious choice for two kinds of work than a plausible option for ten. The third item below is how both of them start.
Product engineering
Multi-tenant platforms built end to end, including the operational surface a business needs in order to actually run the thing.
- Typical duration
- 2–6 months
- Shape
- Fixed scope, milestone billed
- Stack
- Next.js · Postgres · .NET · Go
Plenty of software gets delivered looking finished and turns out to be unrunnable. There is no way to see what customers are doing, no way to correct a bad record, no audit trail when somebody asks what happened, and nothing reconciles. We build the whole system: the customer-facing product, the console the staff live in, and the data model underneath that has to survive contact with an accountant.
What this includes
- Multi-tenant architecture with plan-level feature flags and limits
- Payments, subscriptions, credits and webhook reconciliation
- Ledger-grade data integrity wherever money is involved
- Operational console: tenants, bookings, jobs, usage, intervention
- Audit logs, role-based access and the boring safety work
- Deployment pipelines, environments and rollback
Legacy .NET modernization
ASP.NET Web Forms and .NET Framework applications moved to modern .NET, incrementally and in production, without a code freeze.
- Typical duration
- 3–9 months
- Shape
- Phased, fixed scope per phase
- Starts with
- Modernization assessment
Modernization without the rewrite.
Most modernization projects fail on shape, not on skill. A full rewrite asks a business to run two systems, stop shipping features for a year, and stake everything on a cutover date. We do it the other way: the application is replaced one route at a time while it keeps serving traffic, and every release is small enough to roll back.
What this includes
- Routing boundary so legacy and modern stacks serve one domain
- Unified authentication and session across both stacks
- Route-by-route migration, prioritised by risk and value
- Business logic re-implemented from specification, parallel-run against the original
- Data access modernised: stored procedures reviewed, indexed and instrumented
- Structured logging and health alerting on everything moved
Modernization assessment
Two weeks, fixed price. A written migration plan for your legacy system that is useful whether or not you hire us to execute it.
- Duration
- 2 weeks
- Price
- $4,800 fixed
- Deliverable
- Written plan + read-out
The hardest part of modernizing an old system is not the code. It is knowing the order to do it in. We read the codebase and the database, talk to the people who maintain it, and hand back a document that sequences the work: what moves first, what it depends on, what will hurt, and what it costs.
What you receive
- Codebase and data-layer review
- Dependency and coupling map of the current application
- Route inventory, ranked by migration risk and business value
- Phased migration plan with effort ranges per phase
- Named risks, and the specific things that will go wrong
- Read-out call, and the document is yours to keep
How a live system gets replaced.
The migration pattern, in the order we use it. It is written out here in full because it is not a secret. The value is in having done it before, not in knowing that it exists.
- 01
Draw the boundary
The legacy application goes behind a single routing layer, so the old stack and the new one serve the same domain, the same cookies and the same users. Nothing has moved yet, but from here anything can, one path at a time.
- 02
Unify the session
Authentication is made to work identically across both stacks before a single page is migrated. A user clicking from a twenty-year-old screen into a new one should not be able to tell, and should never be asked to log in twice.
- 03
Move route by route
Pages are migrated in an order set by risk and value, not by what is convenient. Each release is small, independently deployable and reversible. If a migrated route misbehaves, it goes back, and the rest of the application never notices.
- 04
Parallel-run the logic
Where business rules are re-implemented from specification, both implementations run against the same real inputs and their outputs are diffed until they agree. Rules that have been in production for decades have edge cases nobody remembers; this is how you find them before a customer does.
- 05
Retire, then delete
The old page is removed only after the new one has carried real production traffic. Dead code that is still deployed is not migration. It is two systems to maintain instead of one.
Should you rewrite the system or migrate it?
Migrate it, in almost every case where the system still works. A rewrite concentrates all of the risk on one date and pays nothing back until that date arrives. A route-by-route migration returns value in weeks and lets you stop at any point with the work so far still in production.
| Full rewrite | Route-by-route migration | |
|---|---|---|
| Feature work during the project | Frozen, often for a year | Continues throughout |
| First value in production | At the end, on cutover day | Week three or four |
| If something is wrong | The whole release rolls back | One route rolls back |
| Systems running in parallel | Two, for the entire project | Two, briefly, per route |
| Cutover risk | Concentrated on one date | Spread across many small releases |
| Cost of being wrong | The project | One route |
| When the business sees it | After the money is spent | While it is being spent |
The three things people ask first.
How long does a .NET modernization take?
A route-by-route migration of a mid-sized ASP.NET application typically runs three to nine months, phased so that each phase is separately scoped and separately priced. The first migrated route usually reaches production in weeks three to four, which means the approach is proven on your system before most of the budget is committed.
Can you modernize a system without a code freeze?
Yes. The application goes behind a routing boundary, authentication is unified across both stacks, and routes move one at a time while the rest of the system keeps serving traffic. Feature work continues on the un-migrated parts throughout, because nothing is ever globally frozen.
What does a fixed-price software project actually cost?
It depends on scope, but the shape matters more than the number: work is quoted as a defined deliverable for a defined figure, and an overrun is absorbed by the studio rather than billed on. A two-week modernization assessment is the usual starting point, because it produces the plan the fixed price is calculated from.
Three words used precisely.
- Legacy .NET modernization
- Legacy .NET modernization is the process of moving an older ASP.NET application, typically Web Forms or .NET Framework, onto a currently supported .NET version. Done incrementally, the application is replaced one route at a time while it keeps serving production traffic, rather than rewritten and cut over in a single release.
- Multi-tenant platform
- A multi-tenant platform is a single deployed application that serves many separate customer organisations from one codebase and one database, keeping each tenant's data isolated. It usually carries plan-level limits, feature flags and an operations console that staff use to administer every tenant.
- Strangler fig migration
- A strangler fig migration puts a routing layer in front of a legacy application, then moves individual routes to a new stack one at a time. The old system shrinks as the new one grows, and both serve the same domain and session throughout, so there is never a single cutover moment.