Get in touch

Home/Projects/B2B platform for laboratories

Case study · In production

Tody's B2B platform:takeover, modernization

An online ordering platform for laboratories, left without a developer and without up-to-date source code. We took over the servers and the application, rebuilt the code, set up a test environment and a system through which the client approves and deploys each change on their own.

26.5 s → 5.3 ssaving a newsletter, including the recipient calculationmeasured in production
~3 min → ~16 sloading the admin panelmeasured in production
0 differencesafter migrating the database to PostgreSQL 17~30 min downtime
129 pagestested automatically after the code was rebuiltno regressions
The situation

Left without a developer

Tody supplies external quality assessment schemes and materials for medical laboratories, and sells online to laboratories, hospitals and distributors in Romania and abroad. The platform has over 15,000 active products, about 50 customer types with different pricing rules, and 6 currencies.

The application had been built by several developers who no longer worked for the client. The existing source code no longer matched what was running in production, and some admin pages took minutes to load.

Before

  • source code out of date versus production
  • no working test environment
  • admin panel loading in ~3 minutes
  • server and database on unsupported versions
  • uncontrolled changes in production

After

  • complete source code, compiled and verified by us
  • test environment with real data, no emails to customers
  • admin panel loading in ~16 seconds
  • Windows Server 2025 and PostgreSQL 17
  • every change goes through a ticket, testing and approval
What we built

Six parts that work together

The client's application, plus the tools we use to maintain it safely.

Rebuilt source code

Recovered from the version in operation, compiled with the same compiler as the original and compared component by component with production.

Test environment with real data

A copy of production where emails are not sent to customers and card payments run in test mode.

Ticketing app

The client reports issues, approves the cost per requirement, tests, and starts the deployment to the site on their own.

Automatic deployment with rollback

Files and database steps are applied automatically, with file verification, a backup beforehand and a rollback button.

Change detection

Any change to the code or the database made outside the team triggers an alert by phone and email.

Monitoring and backup

The site and login checked every minute; daily and weekly backups in the cloud.

Results

What changed, measured

Grey = before, orange = after. For the newsletter, part of the gain also comes from the move to the new server.

Response times

Newsletter
26.5 s
after
5.3 s
Admin
~3 min
after
~16 s
Report
60–100 s
after
2.3 s

Newsletter and admin panel: measured in production. Sales report: measured in the test environment.

~30 mindowntime during the server and database migration
2,617 → 161queries when saving a newsletter (test)
21 min, 0 errorsfull repair of the EQAS mappings (test)
496tables and views moved to PostgreSQL 17
30background programs restarted after the migration
60 scheck interval for the site and login
Problems solved

Where it was not simple

Lost source code

Problem: the existing source no longer matched the application in production.

Solution: we identified exactly which files had changed from the fingerprints in the production debug files, rebuilt them, fully rebuilt an internal library and compared the result type by type with production.

Slow pages with hidden causes

Problem: the admin panel and the newsletter were waiting on thousands of small queries and on requests blocking one another.

Solution: loading data in batches and running requests in parallel, without changing the application logic.

Migration with minimal downtime

Problem: hundreds of GB of data to move to a new server.

Solution: the data disk was moved directly to the new machine, while the database was copied in parallel and verified with per-table row counts.

How a change reaches the site

From request to production in 5 steps

Ticketthe client describes the request and its urgency
Cost approvedper requirement, approved by email
Testthe change is made and checked in the test environment
Acceptancethe client tests in the test environment
Deploymentautomatic, with file verification and a rollback button

Application

ASP.NET MVCC#NHibernatejQuery

Data and servers

PostgreSQL 17Windows Server 2025Hyper-VPowerShell

Our own tools

PythonDockerPlaywrightUptime Kumantfy
Claude's role

How we worked with Claude at Tody

Each client request becomes a ticket, and each ticket is handled in a separate conversation with Claude.

What Claude did

  • analysis of the code and the database
  • rebuilding the source code and comparing it with production
  • the changes, scripts and tests in the test environment
  • the deployment package, with rollback steps
  • the documentation for each ticket

What we did

  • the decisions: what gets done, when and in which form
  • final verification and measurements in production
  • servers, network and access
  • the relationship with the client

What the client does

  • approves the cost of each requirement
  • tests the change in the test environment
  • starts the deployment to the site on their own

Nothing reached production without testing, rollback steps and a person's confirmation. How we work with Claude on all projects →

Is your application left without a developer?

Tell us what runs and what no longer works. We start with an assessment, not a quote.

Describe your application →