I Built a SaaS While I Slept (And You Probably Can Too)
Everyone is shipping something with AI these days.
My X/Twitter feed is full of "I built this in 2 hours" posts. New AI coding tools drop every week. Models are getting better at an almost uncomfortable pace. And somewhere between the third "look what I vibe coded" video and my morning coffee, I realized I had a problem.
FOMO.
Not the kind where you're worried about missing a party. The kind where you feel like the entire world is learning a new language and you're still reading the phrasebook.
So I decided to do something about it. I built Poromopot-a prompt management platform for teams-in a single night. While I was asleep.
Here's how.
The Idea
The concept came from a real problem at Creasoup, the creative solutions agency I've been running since 2010. We started using AI heavily across client projects-copywriting, brainstorming, content generation, you name it. And pretty quickly, we ran into a mess. Prompts were scattered everywhere. In Slack messages, Notion docs, random text files, people's heads. Someone would craft a perfect prompt for a client's tone of voice, and two weeks later nobody could find it. Another team member would reinvent the wheel for a similar project.
When someone finds a prompt that works, there's no easy way to share it, version it, or find it again.
Poromopot solves this. It's a centralized place where teams can store, organize, and access their prompts-by department, by client, by use case. Think of it as a prompt library for organizations.
I'd been wanting to build this for Creasoup, but kept postponing it. Building a SaaS from scratch? That's weeks of work. Authentication, database, UI, payment integration, deployment...
Or at least, it used to be.
The Setup: PRD → Todo → Sleep
Here's what my evening looked like:
10 PM: I opened Claude and described the idea in detail. Not code-just the concept. What the product does, who it's for, what features it needs. I asked Claude to generate a detailed PRD (Product Requirements Document).
We went back and forth for a bit. Refined the scope. Clarified edge cases. By the end, I had a comprehensive document that covered everything from user flows to data models.
10:15 PM: I asked Claude to break down the PRD into a structured todo list. Every feature, every component, every integration-turned into actionable tasks with clear dependencies.
10:30 PM: I fed the todo list to Ralph.
Meet Ralph (He Works Nights)
Ralph is an autonomous development loop for Claude Code CLI. The name comes from Ralph Wiggum-yes, the Simpsons character-because the original technique was about letting AI "do its thing" without too much supervision.
Here's what Ralph does: it takes your task list and runs Claude Code in a continuous loop. Claude works on a task, completes it, moves to the next one. If it gets stuck, Ralph detects it and adjusts. If it hits rate limits, Ralph waits and resumes. It keeps going until everything is done or it runs out of things to do.
You give it a todo list. It gives you a working application.
10:30 PM: Ralph started running. I watched it complete the first few tasks-scaffolding the project, setting up the database schema, creating the authentication flow. Everything looked good.
11 PM: I went to bed.
Morning
I woke up around 7 AM and checked my laptop.
Ralph had been running for about 5 hours. The terminal showed it had processed dozens of tasks. And sitting in my project folder was... a complete application.
- Full authentication system ✓
- Database models and migrations ✓
- Dashboard UI ✓
- Prompt CRUD operations ✓
- Team and department management ✓
- Search and filtering ✓
- Stripe integration (demo mode) ✓
- Responsive design ✓
I ran npm run dev and there it was. A working SaaS application.
Now, was it perfect? No. Some Tailwind 4 quirks had caused CSS issues on a few screens-buttons that looked weird, spacing that was off. But these were cosmetic problems. The architecture was solid. The logic worked. The data flowed correctly.
I spent maybe 2 hours fixing the visual issues and doing a final review. By lunchtime, Poromopot was live.
What This Means
I want to be clear about something: I'm not a software developer. Not really.
Sure, I started as a webmaster back in the late 90s and early 2000s. I can read code, write some too if I need. I understand how databases work, what authentication flows look like, why you need an API.
Could I have built Poromopot myself, the traditional way? Honestly, probably yes. Eventually.
But here's the thing: every time I'd get stuck on something-a weird error, a library that doesn't work as documented, some authentication edge case-I'd have to stop and learn. Google, Stack Overflow, documentation rabbit holes. Hours would pass. The momentum would die. And at some point, usually around the third frustrating evening in a row, I'd start questioning whether this project was even worth it.
That's how side projects die. Not from lack of skill, but from friction.
The AI removed the friction entirely. It didn't skip any of the steps. It did all of them. Properly. With patterns I wouldn't have known to implement myself. And when it hit problems, it solved them-at 3 AM while I was dreaming about something else entirely.
The New Workflow
Here's what I've learned about making this work:
- Invest in the PRD.
The quality of your output is directly proportional to the quality of your input. Don't rush the planning phase. Be specific about what you want. Clarify edge cases. The more detailed your PRD, the better the Claude & Ralph will execute. - Structure your tasks.
Claude works better with clear, discrete tasks than with vague instructions. "Build the authentication system" is worse than a list of specific components: "Create user model," "Implement email verification," "Add password reset flow," etc. - Use autonomous loops for execution.
Tools like Ralph turn Claude from a conversation partner into a worker. You're not sitting there prompting every step. You're setting direction and letting it run. - Review the output, don't trust blindly.
Claude makes mistakes. Sometimes subtle ones. The code might work but be structured poorly. The logic might be correct but the error handling might be missing. You don't need to be a developer to spot when something feels off-test the flows, click every button, try to break it. If something seems weird, ask the Claude to explain or fix it. - Ship fast, iterate faster.
The old bottleneck was building the first version. Now you can get a working prototype overnight. The bottleneck shifts to figuring out if anyone wants it.
The FOMO Was Right
Here's the thing about FOMO: sometimes it's irrational anxiety, and sometimes it's a legitimate signal that the world is changing and you should pay attention.
The way we build software is changing. Fast. Not in a "this might happen someday" way. In a "this is happening right now and the gap between people who get it and people who don't is widening daily" way.
I'm not saying everyone needs to build a SaaS overnight. But if you've ever had a software idea and shelved it because "I'm not a developer"... that excuse is expiring.
The tools are there. The models are good enough. The techniques are documented.
The only question is whether you're going to watch from the sidelines or get in the game.
Poromopot is now live. It helps teams organize and manage their prompts. If your organization is drowning in scattered AI prompts, check it out.
And if you want to try the overnight development thing yourself, start with Claude Code and Ralph. Your future self will thank your present self for the extra sleep.