We Built Our Own SaaS. Here's What It Taught Us About Building Yours.
Formester is our SaaS product — a no-code, AI-powered form builder used by real businesses every day. Building it changed how we work with every client.
It Started With a Question
We'd been building products for clients for years. Good products. Products we were proud of. But there was always a gap between executing someone else's spec and truly owning the outcome. We wanted to know what it feels like on the other side — to be the ones who lose sleep when something breaks at 2am, who feel the weight of a user churning, who celebrate when the metrics move in the right direction.
So we built Formester. Not as a side project. Not as a demo. As a real product, with real users, real revenue, and real consequences. We wanted to experience every part of the product lifecycle ourselves — from the first commit to the first paying customer, from the support ticket that reveals a blind spot to the feature request that changes your roadmap.
It changed everything about how we work with clients. When you've been the founder staring at your own dashboard wondering why users drop off at step three, you approach someone else's product differently. You stop building to spec and start building to outcome.
What We Built
Formester is a form builder — but that understates it. The surface is simple. What's underneath is not.
AI-Powered Form Creation
Describe what you need in plain English and Formester generates a complete, styled form — fields, validation, logic, and all. Built on OpenAI's API, tuned with thousands of real form patterns.
Conditional Logic for Everyone
Show, hide, and route based on user responses. Complex branching logic that non-technical users can set up in minutes — no code, no compromise.
Payment Processing Baked In
Accept payments directly through forms with Stripe and PayPal integrations. Order forms, donation pages, registration with fees — all without a separate checkout flow.
Real-Time Collaboration
Teams build forms together. Share, comment, iterate. No more emailing screenshots of form drafts back and forth.
Analytics That Answer "So What?"
Completion rates, drop-off points, field-level analytics. Not just data — insights that tell you what to fix and what's working.
No-Code Builder
Drag, drop, configure, publish. The builder is designed for people who have better things to do than learn another tool. Simple on the surface, powerful underneath.
Five Things Building Formester Taught Us
These aren't abstract lessons. They're things we learned the hard way.
The spec is never the product
When we wrote the spec for Formester's conditional logic, it was clean: "If field A equals X, show field B." Simple. Then real users got involved. They needed nested conditions, conditions based on partial matches, conditions that triggered across pages. The spec covered maybe 30% of what the product actually needed. We learned that the real product lives in the gaps between spec lines — in the edge cases, the "what ifs," the things users do that you never imagined. Now when we build for clients, we don't just implement the spec. We stress-test it against reality before writing a line of code.
We challenge specs early. We ask "what happens when a user does X?" before we build, not after. We prototype the risky parts first. We've saved clients months of rework by catching spec gaps in week one.
Technical debt is personal when it's your product
Every engineering team talks about technical debt. But when it's your product — when that shortcut you took six months ago is now causing a bug that's making users leave — it hits differently. With Formester, we've lived with every shortcut we ever took. We've felt the cost of "we'll fix it later" in real churn numbers. That changed our relationship with code quality forever. Not in a "let's over-engineer everything" way, but in a "let's be honest about what we're trading off" way.
We flag technical debt explicitly and help clients make informed tradeoffs. "This shortcut saves two weeks now but will cost a month later. Here's when it'll hurt." Clients deserve to make that call with full information.
Shipping is the beginning, not the end
The day we launched Formester, we thought we were done with the hard part. We were wrong. Launch day is when the real work starts. Support tickets reveal what your testing missed. Analytics show where users actually struggle (hint: it's never where you expected). Feature requests reshape your roadmap. The product you launched is version 0.1 of what it needs to become. We've been shipping updates to Formester every week for years. That rhythm — build, ship, learn, repeat — is now core to how we work.
We plan for post-launch from day one. We build analytics in early. We set up feedback loops. We don't disappear after delivery — 80%+ of our clients stay with us long after launch because the real partnership starts when users show up.
Users don't care about your architecture
We rebuilt Formester's rendering engine twice. The first time, it was architecturally elegant — clean abstractions, beautiful separation of concerns. Users hated it. Forms loaded 200ms slower. Nobody cared that the code was pretty. The second rebuild was uglier but faster. Users loved it. That experience killed any remaining attachment we had to architecture for architecture's sake. Good architecture serves the user. If it doesn't make the product faster, more reliable, or easier to change, it's vanity.
We make architecture decisions based on user impact, not engineering elegance. When we recommend a tech stack or approach, the first question is "how does this affect the person using the product?" — not "how clean is the code?"
Ownership means staying
Anyone can build a feature and move on. Ownership means being there when it breaks at 3am. It means watching your error logs on weekends. It means caring about that one user who filed a bug report at midnight because their payment form stopped working during a fundraiser. We've been maintaining Formester for years. We know what it means to truly own a product — not just the code, but the outcome. The uptime. The user experience. The business result.
We don't build and disappear. PerformLine started with 1 engineer and grew to 8+ over 2 years. Eitoss went from MVP to funding to 2+ years of continued partnership. We stay because we care about what happens after we ship.
The Numbers
These aren't projections. They're the result of years of building, listening to users, and making the product better every week.
Why This Matters for You
Formester isn't just a product we built. It's proof that we know what ownership means. We've felt the weight of a production outage. We've stayed up debugging a payment integration the night before a client's fundraiser. We've watched users struggle with something we thought was intuitive and gone back to the drawing board.
When we say "we build it like it's ours," Formester is what makes that real. It's not a tagline. It's a product you can visit, use, and judge for yourself.
For funded startups
You need a team that understands product thinking, not just feature tickets. We've built and scaled our own SaaS — we know what it takes to go from zero to real users and revenue. We bring that product instinct to your build.
For non-technical founders
You need a team that can translate vision into product without losing what makes it yours. We've been the founders too. We'll guide you through every technical decision the way we wish someone had guided us.
For growing companies
You need engineers who think beyond the sprint. We maintain Formester every day — we know what it means to build for the long run, not just the launch. That perspective shapes every line of code we write for you.