We built, launched, and operate LeadCall, BillBridge, RetroBridge, and PlanItPoker ourselves. Not as portfolio pieces — as actual products with paying users, support inboxes, and uptime obligations. Here is what that changed about how we work on client systems.

You Optimise for Day 500, Not the Demo

When the code is yours and the users are real, the deadline to look good is not the launch date — it is every day after. Error messages that say 'something went wrong' are not acceptable because you have to answer the support ticket. Retry logic that fails silently means a sales manager doesn't get their call logged and you get an angry Slack message at 8am. You write different code when you know you'll be the one on call for it.

Error Handling That Tells You Something

Our internal tools log structured errors with context: what operation failed, what the inputs were, what the external system returned. We pipe these into an alerting pipeline. When a Zoho sync fails because of a rate limit, we know it was a rate limit — not just that 'something was wrong.'

Compare this to what we find when we take over legacy client systems: catch (error) { console.log('error', error) }. That is debugging by prayer. It makes every incident harder and slower than it needs to be.

On-Call Awareness Is a Design Constraint

When you operate something in production, you start writing code differently. You ask: if this breaks at 3am, how quickly can I understand what happened? Can I roll it back without losing data? Can I disable this feature without a deployment? These aren't nice-to-haves. They're design constraints. We bring them to client projects because we've lived the alternative.

The Documentation Nobody Writes

Every production system we operate has a runbook. Not comprehensive architecture documentation — a concise runbook. What does this system do? What are the five most common failure modes? How do you restart the sync worker? Where are the logs? Where are the dashboards?

This exists because we've been paged at 2am and needed to know exactly those things. We write it for client systems too, even when no one asked for it — because six months from now, someone will need it.