From Staging to Production: The Final Sprint

There is a phase of building software that does not get talked about enough. It sits between “the thing works” and “the thing is live.” You have a platform that runs, modules that function, security that passes audits, and a billing system that charges the right amounts. And yet the gap between that and a production deployment that you would hand to a paying customer is enormous. That is where Devalo is right now, and two weeks from today, that gap closes.

The past few weeks have been a relentless cycle of hardening. Not glamorous feature work — the kind of work that makes a platform actually survivable in the wild. Session management edge cases. Ensuring every single API endpoint scopes its queries by organisation. Verifying that the 2FA state machine cannot be bypassed by skipping steps. Encrypting PII fields that were previously plaintext. Building a bootstrap system so the platform can be deployed to a fresh VPS without getting locked out of its own registration flow. These are the problems that surface when you stop building in localhost and start thinking about what happens when a real person on a real connection hits your login page for the first time.

Deployment itself has been an education. Devalo runs on a VPS — not a managed platform, not a serverless abstraction. That is a deliberate choice. When you are building for Australian small businesses and handling their financial data, their customer records, and their booking schedules, you want to know exactly where the data lives and exactly what is running. The trade-off is that every piece of infrastructure is yours to configure. Database connections, SSL certificates, process management, backup encryption, environment variables that need to be airtight before the application will even start. The production validation system in Devalo refuses to boot if it detects weak secrets, localhost origins, or missing encryption keys. That is not a bug. That is the system working as designed.

The module system is in a strong position. The calendar module handles public booking pages, availability management, and appointment scheduling with encrypted client details. The scoreboard module tracks sales performance with live leaderboards and target management. The tasks module — the newest addition — brings task lists, subtasks, templates, and team assignment into the platform. Each module is self-contained, auto-discovered at startup, and scoped to the organisation that owns it. The billing layer underneath enforces seat caps, tier-based pricing, and quota limits per module. None of these modules existed six months ago. All of them were built by one person working with AI tooling in a feedback loop that compresses weeks of traditional development into days.

What has become clear during this final stretch is that AI-assisted development does not just accelerate the building phase. It changes how you approach the hardening phase too. When you can describe a security concern in natural language and iterate on the fix in minutes rather than hours, you actually address things you might otherwise defer. The auto-bootstrap admin system, for example, exists because deploying to a fresh server revealed that the Stripe-dependent registration flow made it impossible to create the first account without a working payment integration. Instead of hacking around it with a manual database insert, the solution was a proper startup hook that checks for an empty users table and creates a fully configured admin account from environment variables. That is the kind of thing that gets filed under “tech debt” in a team environment. Here, it gets solved the same afternoon it surfaces.

Two weeks is not a long time. But the remaining work is not speculative — it is a checklist. Final VPS configuration. DNS cutover. Stripe webhook verification in production. Email delivery confirmation through Resend. A walkthrough of every onboarding path (self-service, business invitation, team member) on the live system. Load testing the calendar booking page. Confirming that the platform admin dashboard shows accurate data across all organisations. The platform is not launching in two weeks because of optimism. It is launching because the architecture was built to be production-ready from the start, and the remaining work is verification, not construction.

Devalo was never meant to be a prototype that grows up. It was meant to be a platform that launches correctly. That moment is close.