Why We Built Formester — and What It Taught Us

Most agencies will tell you they treat your product like their own. We wanted to know what that actually means. So we built one.

Formester is our SaaS product — a form builder that's live, has real users, and holds a 4.7/5 rating on G2. We built it from scratch. Not as a weekend experiment. As a real product with real customers who depend on it every day.

This is the story of why we did it, what it cost us, and the four lessons that changed how we build for every client since.

The Idea Behind Formester

It started with a frustration Ankit kept running into.

Form builders were either too simple — drag-and-drop tools that broke the moment you needed conditional logic — or too complex, requiring a developer to wire up every integration. There was a gap for something that gave non-technical users real power without the engineering overhead.

We could have filed it away as a "someday" idea. Instead, Ankit started building it. Not because we had a business case on a spreadsheet. Because the problem was real, and we wanted to solve it ourselves.

That decision changed how we think about everything we build.

What It's Like to Build Your Own Product (When You're an Agency)

Here's the tension nobody tells you about: client work pays the bills. Product work is a bet on yourself.

Every hour spent on Formester was an hour we weren't billing. Every feature we shipped meant a client feature we had to push back by a day. We had to get disciplined fast — not because we read a book about prioritization, but because we were spending our own money.

There's a moment that sticks with us. Three months into building Formester, we had a list of 30+ features we wanted. We could afford to build maybe eight before launch. The conversation wasn't "what would be cool?" It was "what do users absolutely need on day one, and what can we learn to add later?"

That conversation felt different from anything we'd had with clients before. When it's your money and your product, every feature has a weight to it. You feel the cost of building the wrong thing — not in a budget spreadsheet, but in your gut.

And the bugs? When a user reports a bug in your own product, it doesn't feel like a ticket. It feels personal. Your name is on it. Your reputation is on it. That weight taught us something we couldn't have learned any other way.

The Lessons That Changed How We Build for Clients

Lesson 1: Scope Discipline Is Everything

When you're spending your own money, you learn to cut ruthlessly. We built Formester with a fraction of the features we originally planned — and users didn't care about the missing ones. They cared about the ones that worked well.

This is why we'll tell you what can wait. We've felt the cost of building too much too early. When a client comes to us with a 40-feature MVP, we don't just nod. We sit down together and ask: which three features test your riskiest assumption? Build those. Ship them. Learn. Then build more.

It's not about billing less. It's about helping you succeed faster — because we've been in your exact position.

Lesson 2: Production Quality from Day One

We can't afford to rewrite Formester. It has live users. If the architecture is sloppy, we pay for it every time we ship an update. So we built it right the first time — clean code, proper testing, CI/CD from day one.

That standard carries over to every client MVP we build. We hear "it's just an MVP" from founders sometimes. But here's the thing: if your MVP works, it becomes your product. If you cut corners on the foundation, you'll spend 2-3x rewriting it in six months. We've seen it happen. We refuse to let it happen to our clients.

Build to last, not to demo. That's a lesson Formester taught us the hard way.

Lesson 3: Users Don't Care About Your Architecture

We made this mistake early with Formester. We spent time on technical decisions that users would never see or feel. Meanwhile, a simple UX improvement would have saved them 30 seconds per form.

It reframed how we present work to clients. We don't lead with "we implemented a microservices architecture." We lead with "your users can now do X in half the time." The technology matters — but only as a means to an outcome. If we can't explain why a technical decision benefits the user or the business, we question whether it's the right decision.

Lesson 4: Maintenance Is Where Partnership Lives

Formester didn't end at launch. No product does.

After we shipped the first version, the real work started. User feedback. Bug fixes. Performance tuning. New features based on how people actually used it — not how we imagined they would. The "after" is where the product gets good.

This is why we stay with our clients. We know what post-launch feels like from the inside. When we shipped Eitoss's MVP in 3 months, we didn't hand it over and walk away. They raised funding, and we kept building together. Two years later, we're still their engineering team. That's not a coincidence — it's because we know the product only starts at launch.

Formester Today

Formester is live, growing, and serving real users. It holds a 4.7/5 rating on G2. We maintain it, improve it, and learn from it every week.

It's also our proof point. When we say "we build it like it's ours," we're not reaching for a metaphor. We literally build our own product. The same engineers who work on Formester work on client products. The ownership mindset doesn't switch off.

Why This Matters When You're Choosing a Development Partner

Most agencies build and leave. We build and stay — because we know what the "after" looks like.

When we tell a client "this feature can wait," it's because we've made that exact call on our own product and been proven right. When we insist on clean architecture for an MVP, it's because we've lived with the consequences of our own technical decisions for years.

We're not asking you to trust a sales pitch. We're asking you to look at Formester — a live product we built, maintain, and care about — and decide if that's the kind of team you want building yours.

If you want a team that understands what it's like to be in your shoes — because we've literally been there — let's talk.

This article is part of our commitment to sharing what we've learned from building products — our own and our clients'. Read about how we shipped Eitoss's MVP in 3 months, or learn about our approach to MVP development.