How we built a SaaS in 48 hours using Cynone

Every "I built X in 48 hours" post is either a lie, a demo, or a landing page with a button that goes nowhere. We wanted to know whether a real, revenue-collecting SaaS could actually be shipped in a weekend on top of Cynone, so we did it. This is the hour-by-hour account, including the parts that went wrong and the parts we deliberately did not build.

The product was a small usage-metering and billing tool for other developers: you send us events, we aggregate them, and we invoice your customers based on the counts. It is a genuinely useful product, it is not trivial, and it has exactly the shape of software that most teams would spend two months scaffolding before writing a line of product code.

What 48 hours actually means

First, the honest frame. Forty-eight hours is enough to build a well-scoped product if and only if someone else has already solved the boring 60%: servers, TLS, the reverse proxy, databases, background workers, secrets, and a repeatable deploy loop. That is the entire premise. Cynone is a deployment control plane, so those pieces are configuration, not projects.

It is not enough time for auth beyond a library, for payments beyond one processor, for compliance, for multi-region anything, or for a product people did not already want. We picked a product whose users we knew, and we spent zero hours on features nobody asked for.

Hour 0–8: the plumbing disappears

We connected a Git repository, and the first deploy came up on a temporary domain with TLS in under an hour. That includes framework detection, the build, the health check, and the point where a browser could actually load the app. Most of that hour was waiting for the build.

By hour three we had pointed our real domain at the release and the certificate was issued automatically. No DNS tricks beyond a single record, no manual Nginx config, no certbot ritual. The reverse proxy and certificate lifecycle are things the platform owns, and the difference between doing this by hand and doing it here is the difference between an afternoon and a coffee break.

Hour five was secrets. Database credentials, the Stripe key, an encryption key — each in the environment configuration, masked in the UI, never in the repository. We had been burned by a .env in a repo before, and the fact that secrets were a first-class, versioned concept here meant the discipline cost us nothing.

Hour 8–20: data services beside the code

The metering product is a Postgres write-then-aggregate workload with a Redis layer for hot counts, so we provisioned both as managed services next to the application. The meaningful part is that they are provisioned with the rest of the deployment, in the same control plane, with backups configured before we ever wrote a production query.

We did not need to be database administrators to get a production-grade Postgres. The connection string, the backups, and the health signals were all there in context, and the time we would normally have spent on server setup went into the schema — which is the part that actually mattered.

This is the point where the 48-hour claim usually breaks, so let me be precise: two managed data services, one schema, one migration. That was the entire data plane. Anything more — replication, multi-region reads, failover testing — would have blown the budget, and none of it was needed to take a first paying customer.

Hour 20–32: the worker that does the work

The metering product has two jobs that cannot run in a web request: aggregating event counts into invoices, and emailing those invoices to customers. Both went onto a background worker process — a separate command, separate resource controls, same repository, same release.

The scheduler ran the aggregation as a recurring job, and the queue worker consumed invoice jobs with retries and backoff. Nothing about this required infrastructure imagination. A worker process is just another command in the release, and the platform keeps it running and restarts it on failure, the same way it does the web process.

Hour 30 had the first real bug: a job that re-queued itself on failure in a way that could loop. It showed up in the logs, we fixed the guard in a commit, and the preview environment for the pull request let us verify the fix without touching production. This is the loop the whole weekend depended on, and it worked every single time we used it.

Hour 32–44: previews and the deploy loop

By hour 32 we were not building features anymore; we were in the iterate cycle that produces software people trust. Every pull request spun up a preview environment with its own database and URL, so the code review was also a product review. The phrase "looks fine in the code" stopped being a thing because there was always a running version to click.

The deploy loop was the same one every engineer on the team already knew from other projects, except faster and with rollback. When a billing change went out and a customer-facing page mis-rendered, the rollback was a click, not a fire drill. The previous release was still there, still signed, still runnable.

Hour 44–48: what shipped

At hour 48 the state of the world was: a live product at our own domain with working TLS, a free tier and a paid tier billing through Stripe, Postgres with automated backups, Redis for hot counts, a worker handling aggregation and invoice email, preview environments for every pull request, and a handful of paying customers.

What did not ship: a billing dashboard beyond the bare minimum, a public API with rate-limit documentation, a changelog, any kind of onboarding email sequence, and every edge case in invoice proration. We listed them out loud at hour 47 and agreed they were all follow-up work, not blockers. That list is why the deadline held.

What the platform actually bought us

A fair accounting of the 48 hours: roughly twenty of them went to product logic, schema design, and billing flows. The other twenty-eight were deployment concerns — and on Cynone they took maybe four hours of attention, spread out. The rest of that time went to waiting for builds and deciding what to build next.

That is the real number. The platform did not make us faster at writing the product. It deleted an entire category of work — the plumbing — so that the twenty-eight hours of deployment concerns collapsed into four, and the saved time went into the product and into talking to the first customers.

The honest caveat is that a weekend build is a start, not a company. The weekend got us to first paying customers and a stable loop; everything after it — reliability engineering, scaling, a second region, compliance — is the work that the 48 hours made possible. But you cannot do the work that comes after launch if launch never happens. The platform is the reason launch happened, and it happened on a Sunday evening.