carrd.coGet started
← All posts

Why Narrow Beats Big: An App Development Company Lesson

Ankit931 wordsapp development company

You don't need a big app development company to build something real. I know because I built Carrd, a one-page site builder, mostly on my own, and the thing that saved me wasn't a bigger team or a fancier stack. It was saying no to almost everything.

Here's how that played out, and what it might mean for you if you're weighing whether to hire an app development company or just start small yourself.

Why did I break the project into five pieces?

By my old standards, Carrd was huge. Big enough to be intimidating. So instead of staring at the whole mountain, I split it into five subprojects, the Generator, the Builder, the Dashboard, the Site, and the Paid Plan, and worked them one at a time.

That's the whole trick. A big project you can't start is worth less than a small one you can finish. Cutting it into five let me make progress without the entire thing looming over me every morning.

How do you pick something small enough to build alone?

I'd spent years designing and coding site templates, then building sites to hand them out. Good work, but it went routine. I wanted something new. The open question was what.

The answer came from staying close to what I already knew. Instead of chasing a wild, unfamiliar idea, I looked one step sideways from my existing skills, and the next logical project showed up. A builder for one-page profile sites. For a solo build, that niche checked the boxes. Simple, wide appeal, already proven popular. That made it the strongest bet I could place.

Any app development company will tell you scope creep is what kills projects. The fix isn't more people. It's picking a lane narrow enough that one person can actually see the end of it.

What does a narrow focus actually buy you?

The whole product is built around one pattern, a simple "stack" of elements. That's the site spec. You add elements, you arrange them, you customize the details that matter. Because everything lives inside that one idea, there's a natural limit to its complexity, for me building it, and for you using it.

That narrow focus is the hero here. It's why the thing stays easy to use instead of turning into another do-everything tool nobody can figure out.

  • Simply built. One core pattern, not fifty features fighting each other.
  • Customizable. Deep control on the details, without the overwhelm.
  • Responsive. A mobile-friendly builder, not just mobile-friendly sites.

Did going framework-less pay off?

For the Builder, I skipped the popular frameworks and hand-rolled the frontend with plain JavaScript and a bit of jQuery. Risky? Sure. But it meant the tooling bent to fit the Builder instead of me bending the Builder to fit the tooling.

The bonus. I knew exactly how every part worked, which made bugs easier to chase and features easier to bolt on. It also forced me to learn things a framework would've quietly handled for me. Worth trying at least once, even if you never do it that way again.

The design came from a sketch made years earlier

I had a rough picture of how the Builder should look from back when I first dreamed up the project in early 2015. I did a mockup before I'd even started on the Generator. A few months of nudging it around, and I landed on something that looked a lot like the final UI.

The Dashboard followed the same instinct. Make the user's own sites the centerpiece. Big, auto-generated screenshots, front and center. The same screenshot-first idea that worked for the Builder worked again for the hub. Reuse what already works.

Even the name was a constraint problem

The name shows up inside people's own subdomain URLs, so it had to be short, memorable, and low-key enough not to stand out. Add the fact that snappy two-letter domain extensions are hard to grab, and naming turned into its own little puzzle. Carrd, at carrd.co, was the answer that fit.

What I'd tell anyone building solo — or hiring it out

If you take one thing from all this, take the list I wish someone had handed me:

  • Don't try to do too much. Limiting the focus is the only reason one person could build this at all.
  • Don't obsess over competitors. Watch them too closely and you'll box yourself into their shape.
  • Stick to your vision, but stay a little flexible. A user asking for multiple pages is what led me to the Control Element — a good idea I hadn't planned for.
  • Don't force a signup just to try the thing. Let people play first.
  • Plan away from the screen. Paper and a whiteboard gave me clarity a monitor never did.
  • Test on real devices. Emulators lie. Real phones don't.
  • Talk to people. Twitter and Product Hunt were priceless for feedback and support.
  • Have fun. Seriously.
Would a full app development company have built Carrd faster? Maybe. But they could just as easily have padded it with features that buried the one thing that makes it good. The narrow focus was the whole point, and short of me royally screwing up, it's what keeps the product simple enough to be capable of cranking out a gorgeous site in under 5 minutes.

All of that looked great on paper. The real test was how it would play out in practice, and, much to my surprise, the results were good. Really good.

Frequently asked questions

Do you need an app development company to build a simple site or app?

Not really. Carrd got built mostly solo by keeping the scope narrow and breaking the work into five small subprojects. The bottleneck usually isn't the size of the team, it's a scope that got too wide. Trimming the focus down tends to matter more than throwing people at it.

How do you pick a project a small team or one person can actually finish?

Stay one step sideways from the skills you already have. For a solo build, a niche that's simple, has broad appeal, and is already proven popular is your best bet. That's exactly how the one-page profile site idea came up.

Why build around a single pattern instead of lots of features?

One core idea, a simple stack of elements, puts a natural limit on the complexity. That keeps the product easy to use and keeps the build doable for a small team, instead of ballooning into a tool nobody can figure out.

Is it worth going framework-less?

It can be, at least once. Hand-rolling the frontend with plain JavaScript and jQuery let the tooling fit the Builder, gave me full knowledge of how everything worked so bugs were easier to fix, and forced me to learn things a framework would have hidden.

What's the biggest lesson from building a product solo?

Don't try to do too much. Keeping the focus narrow is what made the whole thing possible for one person, along with planning away from the screen, testing on real devices, and not making users sign up just to try it.

A
Ankit
Developer

Started as a solo developer tired of watching non-technical friends pay agencies for a single landing page. Stripped web building down to forms, blocks, and a domain — nothing else. Now used by musicians, consultants, and side-project founders who want a form that collects emails or takes payment without touching code.