Prefer a weekend project. You get a taste of the old feeling: an idea, a laptop, no meetings, a thing that works on your machine at 11pm and makes you feel 22 again even though your back knows you are 42.
Some of those projects should stay toys. That’s healthy. Some of them accidentally become the thing the team opens on Monday. That’s when the trouble starts, because production is not a feature you add. It’s a set of promises.
There is promoted enough weekend tools to have a checklist Trust more than my Sunday confidence. The hack can be messy. The promises cannot.
The moment it stops being yours
A weekend project is production when someone else would be blocked if it vanished. That’s the line. Not “it has a domain.” Not “I used a real database.”
If admissions is using your queue, it is production. If marketing is generating posts from it, it is production. If you are the only one who knows how to restart it, you are now on call, congratulations, you built a job.
I try to notice that moment without drama. Then I either promote it on purpose or I take it away before people build habits on a sandcastle.
Taking it away is allowed. “This was a demo” is a complete sentence. It is kinder than letting a toy set the company’s morning.
What to add before you hand anyone a URL
Auth. Even if it’s a shared password for a week, it is not an open tab on the internet. Then real logins. Then roles, because the intern does not need the delete button.
Backups. If the state lives in a SQLite file on a homelab box, that’s a story, not a strategy. Snapshot it. Know how to restore it. Test the restore once, or you have a backup folklore.
Logs you can read without SSH folklore. A health check. A way to deploy that is not “Remember the steps.” Env-based secrets, not keys in the repo from Friday night.
None of this is glamorous. All of it is cheaper than a Monday where the only copy of the truth was on a disk that decided to be a paperweight.
Don’t rewrite it because it feels embarrassing
The urge, when something gets real, is to rebuild it “properly.” New framework. New folder structure. New delay.
I rarely do that first. I wrap the ugly core in the production promises. Put a reverse proxy in front. Add auth. Add backups. Add a status page. Keep the thing that already works.
Rewrite when you understand the usage, not when you are ashamed of the code. Shame is a bad architect. Usage will tell you which parts are actually load-bearing.
AI coding agents are great at this promotion work if you brief them like an adult. “Add session auth. Don’t change the queue logic. Don’t invent a new database.” Small diffs. Tests if you can. See also: every time I skipped that and got a rewrite of the app because Mercury was in retrograde.
Make it operable by someone who is not you
A production weekend project needs a README that would survive you getting the flu.
- what it does
- how to run it locally
- how to deploy
- where the data lives
- what to do if it’s down
- who is allowed to change prompts, if AI is involved
If the only runbook is in your head, you didn’t ship a tool. You shipped a dependency named Kevin.
Also add a kill switch for anything that talks to customers. Prompts go weird. Vendors go down. You want a way to fall back to voicemail or a human queue without digging through code during a live event.
Data gravity will surprise you
The weekend tool starts as a viewer. Then people type notes into it because it’s on the screen. Now it’s a system of record and you didn’t notice.
I try to decide early: is this a window into the CRM, or is this the place the truth lives? If it’s a window, write back. If it’s the truth, treat it like a database you would be sad to lose, because you will be.
Migration later is possible. Migration later while the team is in the middle of a Monday is a personality test.
When you leave it as a weekend project
If it only saves me time, it can stay scrappy. If it would confuse a customer, it stays local. If I cannot explain the failure mode, it doesn’t get a public URL.
Not every idea deserves a promotion. The skill is picking the ones that already have a job, then dressing them for the job they got.
The punchline: weekend energy is how good internal tools start. Production manners are how they get to stay. You can keep the spark without pretending a Sunday deploy is a company.
Bottom line
Build fast. Promote on purpose. Write down how to reboot it. Then go outside. The project will still be there on Monday, which is the whole point of doing the boring part.
