5 Principles That Helped Me Build ProseBird
Five principles that made building a SaaS as a solo developer a LOT easier.
1. “Your idea shouldn't adapt to you”
ProseBird taught me more in a few months than four years of college ever did. The reason is simple: I didn’t build around what I already knew. I built what the idea demanded, and learned the skills as I went.
Taking on ProseBird meant being okay with stepping out of my comfort zone and starting from scratch in many ways. When I started, I didn’t know Next.js, Tailwind CSS, TypeScript, Stripe, PostHog, the list goes on. But catering to my project's needs instead of my own meant I had to figure them out, one by one, sometimes even multiple at once.
And those were just tools. Let alone how individual features forced me to dive into entire areas I had never touched. Stuff like string distance algorithms (Levenshtein) for the spoken-word alignment system, or voice-to-text AI and speech recognition.
Imposing limits on your product just because they exceed your current skills is one of the worst things a technical founder can do. If you want to grow fast, your skill set has to follow the idea, not the other way around.
2. “Don't run away from hard problems”
It’s natural to want to avoid work that feels like it’ll drain a disproportionate amount of time and energy. For me, nothing amplifies that feeling more than uncertainty.
To me, spending hours coding isn’t the end of the world. Maybe you hit a few bumps along the way but at least you can see the finish line. On the other hand, if I’m using that same time and energy digging through new documentation and searching for the “ideal” implementation, that’s a mind-numbing game with no end in sight, one that often leads nowhere.
Regardless of the type, putting off problems like these won’t make them disappear, you’ll have to face them sooner or later. In my experience, whether I tackle an issue right away or put it off for a week, the result is almost always the same: it takes just as long to solve. The only difference is that I ended up delaying progress by a full week for no reason.
You probably won’t wake up tomorrow with a breakthrough that drastically reduces time and effort. So you might as well start now and be done by then.
On top of that, starting with the biggest concerns in a project is often the smartest path forward. These are the problems that tend to define the viability of entire sections, or even the whole project. Solving them early gives you a much clearer picture of both feasibility and strategy.
3. “Don't paste code you don't understand”
This one might be controversial since most developers are guilty of it at some point. And with the rise of vibe coding, falling into this trap is easier than ever. But what makes committing to code you don’t quite understand such a bad thing?
Let’s say you’re working on a school project due in four days.
Day 1:
You paste a useEffect or setTimeout from StackOverflow or ChatGPT. You don’t really get it, but it works, so you move on.
Day 2:
You add a custom hook, then debounce, then a library. Logic overlaps and you patch bugs without knowing what actually fixed them.
Day 3:
By this point it’s a black box you’re afraid to touch. You comment stuff out, rewatch tutorials, copy even more code but nothing actually solves the root problem.
Day 4:
Deploys break, you stop refactoring, momentum dies. Now you have to pull an all-nighter, rewrite half of your codebase and pray to be done by the time the sun comes up. Yikes.
A full-on snowball effect, all because you didn’t stop to understand the first few lines.
Personally, once I started treating StackOverflow and AI as teachers instead of shortcuts, I never needed them more than once or twice with any given problem before I could solve it confidently on my own.
4. “Hold the bar as high as you can”
When I say “bar,” I mean the metaphorical one, the standard you use to decide whether something is “good enough”.
Mine’s been comfortably high for as long as I can remember. Credit goes to my mom, who drilled that into me early on, and I, for either fear of repercussion or plain peer pressure, held onto it through middle school, high school, and college. Not the best of reasons, but hey, I turned out fine.
Jokes aside, this mindset is one of the most OP life traits you can develop, because it works like a muscle. The more you hold yourself to a high standard, the sharper your critical thinking and prioritization skills get. Whether you're judging someone else's work or doing something yourself, you can tell if it's good, bad, or absolute garbaggio, and you'll often be right.
Living by this naturally takes a toll on your well-being. The tradeoffs are mild neuroticism, hair loss and a potentially shorter life expectancy, but it's not like you can't turn it off from time to time.
In fast-paced environments where speed matters, this principle can easily be mistaken for paralyzing perfectionism. That’s not the point. It’s less about shipping perfect work right away, and more about knowing what a high-bar outcome looks like, then work toward it with every iteration.
5. “When your body talks, you listen”
This last one is simple, but often overlooked, and I couldn’t leave it out.
Before I internalized this as a principle, I lost countless nights trying to brute-force my way through problems to no success, only to revisit the same issue the next morning with a fresh perspective and solve it in a fraction of the time.
The idea is simple: your brain stops working right past a certain threshold of stress or exhaustion. That threshold varies from person to person, but once you hit it, you’re just wasting time pretending otherwise.
In my experience, pushing through those limits is often encouraged, sometimes even romanticized, as part of the hustle that comes with building something on your own. And sure, there’s truth to that. I still try to push myself when it counts.
But the real skill is knowing when to call it a day. Otherwise, it turns into a pointless game with no winners.
