Escaping the boilerplate loop: the story behind Start UI

The boilerplate trap: losing precious time before the real work begins

If you’ve ever built software, you know exactly how it goes. A new project lands on your desk, and before you even get to tackle the real problems, you’re already knee-deep in setup hell. You’re running “npm install” for the hundredth time, tweaking configurations, copy-pasting snippets from old projects, and patching the same bugs you swore you’d never see again. It’s like being stuck in a never-ending loop, except the only thing changing is how much coffee you need to survive it.

Nobody really talks about this part. Everyone loves showing off their shiny new features or the cool tech they’re experimenting with, but no one admits how much time gets wasted just getting the basics up and running. Meanwhile, the clock is ticking, clients are already asking for updates, and your team is split between “let’s just ship it” and “let’s do it right.” Spoiler alert: both sides usually end up frustrated.

This is the real pain point. Every hour spent wrestling with boilerplate is an hour you’re not building anything valuable. There’s only so many times you can type “npm install” before you start questioning your life choices. And it’s not just about lost time, it’s about quality too. When you’re rushed, you cut corners, and suddenly you’re stuck maintaining a codebase held together by duct tape and wishful thinking. In this industry, if you’re not moving fast, you’re just making yourself an easy target for someone who is.

The “Meow” moment: how it all began

Let’s rewind a bit. Before Start UI, there was “Meow”, a JHipster blueprint named after one of the JHipster cat mascots (because why not?). Ivan, my co-founder, was tired of reinventing the wheel every time we needed a frontend. JHipster HAD a front-end, but it was not including strong typing or standards of the time. Probably because “J” stands for Java, not JavaScript…

So we leaned on JHipster for the backend and hacked together our own frontend starter. It kinda worked until we decided to switch everything to TypeScript. That’s when the cracks started to show. JHipster’s backend and our shiny new TypeScript frontend just didn’t play nicely together. Instead of fighting mismatched tools, we made a bold decision: Rebuilding our own backend from scratch exactly the way we wanted it. That decision laid the groundwork for our current stack: TypeScript everywhere, tRPC for APIs, Prisma for databases, and Lucia for authentication. No more patchwork solutions but just a clean, modern setup that finally felt right.

Beyond the repository: the real impact of Start UI

Start UI began as a simple time-saver but quickly evolved into our team’s central knowledge base. Every fix, every lesson learned, every clever workaround documented and shared. No more digging through old projects or asking around for that elusive solution someone vaguely remembers. If we’ve solved it once, it’s in Start UI, ready to go for the next project.

Collaboration improved overnight. Pair programming and mob sessions became genuinely productive because everyone was working from the same, up-to-date codebase. Junior developers could jump in without stumbling over legacy hacks. The code was consistent, patterns were clear, and the team could finally focus on building features instead of cleaning up messes.

On the business side, the impact was immediate. Project setup time dropped from weeks to just a day. Clients pay for one or two days of setup but get a foundation that would have cost them significantly more. This frees up budget for actual features, not boilerplate. For us, it means faster delivery, fewer bugs, and less time wasted on repetitive tasks.

We open-sourced Start UI for several reasons explained in our first article. First, public code forces higher standards so no more hiding shortcuts or ugly hacks. Second, it’s a real portfolio piece, not some NDA-locked project nobody can see. Third, it’s a reference point for our team and a way to give back to the community that’s given us so much. Finally, it’s a sandbox for testing new ideas before they hit client projects.

External contributions have been an unexpected bonus. Developers outside our team have fixed issues and added features we hadn’t even considered. Every contribution makes Start UI stronger. Today, it’s both our calling card for clients and our Code Playground for innovation. That’s the real value.

Precision and purpose: the thoughtful tech stack behind Start UI

Start UI isn’t just another web starter, it’s an opinionated starter, carefully crafted ecosystem spanning web, native, and design. It’s not a jack-of-all-trades tool made to satisfy every need. Instead, it’s a specialized set of tools, configured to work together in a way which matches real world business needs.

We didn’t want a Frankenstein’s monster of mismatched tools. We wanted something integrated, cohesive, and intuitive, which follows our standards and culture. That’s why we built out a unified web stack, a matching native stack, and even a Figma design system that mirrors our components pixel-for-pixel.

Every technology choice was deliberate. We picked tools that made sense for us not because they were trendy, but because they were maintainable, understandable, and genuinely useful. No buzzword bingo, no chasing the latest hype. Just solid, reliable tech that gets the job done.

Our design philosophy was simple: alignment. Components in the codebase match components in Figma. Designers and developers speak the same language. No more “that’s not what I designed” or “that’s impossible to code.” Everything lines up, and everyone knows exactly what to expect.

This was the Start UI v2 stack, for the v3 we changed a bit, including ditching Next.js…

Conclusion: breaking free and building better

We built Start UI because we were stuck in boilerplate jail. Meow was the first try, then TypeScript broke the old comfort zone, so we dropped the JHipster backend and went all in on one stack that we control, TypeScript everywhere, tRPC, Prisma, Lucia. From there it stopped being a repo and became our shared memory. Fewer pixel fights because Figma and code match, less glue code, setup in one day, juniors ship on day one, seniors stop babysitting configs. Clients get a solid base without paying for six weeks of plumbing, we spend budget on real features, quality goes up, stress goes down. Open sourcing forced cleaner choices and brought outside fixes we did not expect, it also gave us a clear reference for talks, trainings, and the next projects.

Presentation of an old version of Start UI

Presentation of the latest version of Start UI

Opinions made the difference. Not loud opinions, useful ones that cut noise and set boundaries. Fun fact, I got a client because of that. He forgot the name Start UI, he was hunting for ops people, but he remembered the punchline Opinionated, and called when he needed someone with a real stance. I will tell this story in a future article.

Names fade, a clear opinion sticks and converts. We keep polishing the stack in the open, with rules that protect focus without turning it into a zoo. In the next article, we will explore our new Iteration on Start UI and where the starter is heading.