Startup case study: scaling with Cynone

This is the story of a two-person startup we helped move off a platform that was quietly eating their margin, told with the numbers they shared with us. The names are changed because the founders are still running the company; everything about the trajectory is real. If you are a founder reading this, the mistakes are the point.

The company sells a scheduling and reporting tool to small retail chains. Two developers, maybe two thousand paying users at the time of the move, and a product that was growing because it genuinely worked. The infrastructure was a Heroku app with a managed Postgres, and it was the most dangerous kind of setup: one that still worked.

Where they started

The Heroku bill was their second-biggest line item after payroll, and it grew faster than revenue because the database and the dynos scaled up before the growth justified it. Deploys were a git push with a prayer, there were no preview environments, and every release was a small bet that the migrations would not take the site down.

The moment that broke the setup was a routine release: a migration that locked a table during business hours. The site went slow, support got tickets, and the founders spent a Tuesday afternoon explaining an outage to customers who did not care about their stack. That afternoon cost them more than any platform fee.

The move

They moved the app, the Postgres database, a Redis cache, and a background worker to Cynone over one weekend. The deployment was the same code, the same domain, the same customers — the only visible change was the bill. The migration itself was mostly about the database: a dump, a restore, a switch of the connection string, and a week of watching the new setup for drift.

What changed in the first week was not performance. It was the operating loop. Previews appeared for every pull request, so the founder who did not write code could click a URL and test a feature. Deploys became repeatable and reversible. The reverse proxy and TLS stopped being a thing anyone thought about. None of this showed up in a benchmark; all of it showed up in how the founders spent their evenings.

Scaling from 10k to 100k users

The growth from ten thousand to a hundred thousand users was where the setup was tested, and the honest summary is that the platform did not do the scaling for them — it removed the friction that made scaling scary. The steps were ordinary and mostly boring:

1. 01 At roughly 20k users, the database was the constraint. A few missing indexes and a set of N+1 queries were found in the slow-query log and fixed in a week. The p99 dropped by half.
2. 02 At roughly 40k users, the web dyno was right-sized and a second replica was added for the morning spike. Statelessness made this a configuration change, not a refactor.
3. 03 At roughly 60k users, Redis was added for session and catalog caching, and a queue was introduced for the report generation that had been blocking request threads.
4. 04 At roughly 80k users, the worker was split so that scheduled report batches did not compete with real-time email delivery.

None of these steps required an architecture rewrite, a hiring spree, or a "we need to talk about scale" meeting. Each one was a small, reversible change made in the same control plane as everything else, with previews to test it and rollback if it misbehaved. That is the whole case study, really: scaling happened the way it should — gradually, safely, and without drama.

The boring wins came first

The founders' instinct, like most founders, was to plan for the future scale and over-provision for it. The wins that actually moved the numbers were the ones that cost nothing and scaled nothing: an index on a foreign key, a query rewritten to avoid a full scan, a cache key that was missing a user id and serving stale data.

One report endpoint, the one their biggest customers opened first thing in the morning, was rendering a dashboard with eleven queries instead of three. Fixing it was an afternoon of work and the single biggest latency improvement of the whole engagement. Nobody remembers the scaling infrastructure; everybody remembers the report being slow.

What they almost did instead

Somewhere in the middle of the story, a well-meaning consultant told them they needed Kubernetes. They were two people. They would have spent a quarter running the thing they built to save them from running things. They almost did it anyway, because "everyone runs Kubernetes" is a strong gravitational pull.

They also almost moved to microservices because a single endpoint was slow, and they almost bought a dedicated database cluster for a workload that needed an index. The common thread in all three near-misses is the same: architecture as a status symbol. The fix that worked in every case was a small, boring change at the layer that was actually slow.

The numbers after six months

Six months after the move, the platform cost was roughly a fifth of what Heroku had been charging for the same workload. Deploys went from a nervous git push to a repeatable pipeline that took about three minutes from commit to production. Change failure rate — the share of releases that caused an incident — went from roughly one in four to one in forty.

The founders' favourite number was not cost or latency. It was mean time to recovery, which collapsed because rollback became a click. The incident that once cost them a Tuesday afternoon would now cost them a minute, because the previous release was always one click away. That is the number that lets a two-person team sleep.

What Cynone actually provided

For the record, the honest boundaries. Cynone did not make their code faster, did not write their indexes, and did not remove the need for them to understand their own database. What it provided was the scaffolding that normally eats startup time: the deploy loop, the previews, the reverse proxy and TLS, the managed data services with backups, the worker lifecycle, and the instant rollback.

In practical terms, it collapsed the distance between "we want to ship this" and "it is live and we can undo it." For a two-person team, that distance is the whole business.

Five lessons for other startups

1. 01 Scale in the order that costs the least first: indexes, queries, right-sizing, a cache, a queue — replicas last.
2. 02 Never plan an architecture for a scale you do not have yet. The workload will tell you what it needs, usually in the slow-query log.
3. 03 Preview environments are a hiring tool disguised as a feature; the second person on the team needs them more than the first.
4. 04 Rollback being cheap changes team behaviour more than any speed-up. Fearless deploys produce better releases.
5. 05 Ignore the people selling you infrastructure. Kubernetes is not a milestone; paying customers are.

A hundred thousand users is not an infrastructure achievement, it is a product achievement that infrastructure declined to ruin. The boring, reversible, boring steps are the whole story. Any founder can do what they did — the platform just removes the part that usually stops them.