A Dubai recruitment startup came to Softwise with a prototype built fast by a previous vendor: paying customers, weekly outages, and no path to new features. We rebuilt it as a production SaaS using a strangler-pattern migration, moving one module at a time while the old system kept serving customers. Every cutover was reversible and customers never saw a migration.
Anonymized by design: industry and city, not names. The shape of the problem is the point.
A recruitment startup in Dubai matching companies with vetted candidates. The founding team had a vendor build the first version fast. It won real customers, which is exactly when it started failing: timeouts on candidate search, a shared login for all admin roles, and a schema nobody could extend.
The trap with a successful prototype is that you cannot turn it off to rebuild it. Revenue depends on the thing you need to replace. A big-bang rewrite with a launch day is how companies lose their customer base in one weekend.
Paying customers on the old system. Revenue ran through the prototype every day. A launch-day rewrite meant betting the customer base on a weekend cutover, which the client had already been advised to do and rightly refused.
No documentation, one ex-vendor. The prototype came with no docs and an ended vendor relationship. Every behavior had to be recovered from the code and the logs before it could be replaced.
Dubai data residency. The new platform had to host in-region from the first module, not as a later migration, and billing ran on Stripe's UAE stack from day one.
Decisions, not adjectives. Each one had an alternative we rejected.
The new platform grew around the old one. A routing layer sent each module's traffic to old or new, and modules moved one at a time: authentication first, then search, then matching, then billing. Every cutover was reversible within minutes. Customers never saw a migration.
Most of the prototype's failures traced to its schema. We designed the target model up front and made every migrated module write to it, so the rebuild paid down data debt as it went instead of carrying it across.
Candidate search moved from LIKE queries over a flat table to a properly indexed search service. Queries that timed out under modest data volumes return consistently as the candidate base grows.
The prototype's shared admin login became proper role-based access: recruiter, hiring manager, and administrator each see and can do exactly what their role allows, with an audit trail underneath.
Each migration followed the same routine: shadow-read both systems, sync writes, move reads, then flip the route. The playbook made the fourth cutover as boring as the first, and made rollback a routing change rather than an incident.
Delivery order matters as much as what was built. Each phase had to be safe to stop on.
Reconstructed the prototype's actual behavior from code and logs, designed the target schema, and stood up the routing layer with all traffic still on the old system.
Moved authentication first because every later module depends on it, then search because it caused the outages. Both cutovers were reversible and neither was noticed by users, which was the point.
Moved the matching engine onto the new data model, then billing last, with Stripe collection running through the new platform before the old billing code was retired.
With all traffic on the new platform, the prototype was frozen, archived for compliance, and its infrastructure retired. Feature work resumed on the new codebase within weeks of engagement start.
Qualitative outcomes and engagement shape, without invented numbers.
The timeout-driven outages ended as search and matching moved onto the new platform, and no cutover was visible to a single customer. Revenue ran uninterrupted through the entire rebuild.
New feature work restarted on the new codebase within weeks of engagement start, after months during which every estimate on the prototype had kept growing.
The target schema absorbed every post-migration feature request without a breaking change, which the prototype's schema could not do even once.
The questions this project is usually asked about. Still stuck? Ask us directly.
Yes, with a strangler-pattern migration: route traffic module by module from the old system to the new one, keeping every step reversible. The old system keeps serving whatever has not moved yet.
When the data model itself blocks new features, or when reliability failures cost customers. If outages recur in the same subsystems and every feature estimate keeps growing, patching is paying interest on a debt that a rebuild retires.
Yes. The first step is a code and infrastructure audit to decide what survives. Salvaging working modules is cheaper than pride. Rebuilding everything is only right when the audit proves it.
Module by module behind a routing layer. Each module runs shadow reads against both systems, syncs writes, then moves reads, and only then flips the route. Every step is reversible in minutes, so a rollback is a config change, not an incident.
Once every module has moved and the routing layer sends no traffic to it, the old system is frozen, archived for compliance, and its infrastructure retired. Nothing is switched off until nothing depends on it.
Different industries, same in-house team.
/001/Softwise built a multi-tenant field-service SaaS for an operations company in Riyadh. One codebase serves every customer through a shared-sc…
Read more →
/002/Softwise built a home-services super app for a Tunis marketplace startup: cleaning, repairs, and delivery verticals in one native mobile app…
Read more →
/003/Softwise connected a Lyon distributor's ERPNext instance to its e-commerce storefront and third-party logistics provider. Orders, stock, and…
Read more →
/005/Softwise integrated AI document extraction into a Paris insurance firm's existing claims process without replacing any system the staff used…
Read more →
/006/Softwise built fleet and park management on top of ERPNext for a road-freight company in Tunis running a mixed truck and van fleet. GPS tele…
Read more →