A small team, a hard problem, and a tool that lets us ship without tests. This is Meticulous.
We don’t write tests at Meticulous.
Not for the frontend, anyway. We refactor freely, upgrade libraries without flinching, and ship features in roughly the time it takes us to write them. The bug-catching happens somewhere else.
I want to tell you how I ended up here, and why I think it matters.
The interview
A friend referred me to a YC-backed startup with five engineers. I was at Bloomberg, I wasn’t planning to leave, but the description was interesting enough that I went through the process.
The process was long:
- 2 leetcode-hard technical interviews
- 2 system design
- 3–5 behavioral, depending on how you count the “walking chats”
Every problem seemed harder than the one before. By the end I was less worried about getting an offer and more curious about who else had survived this.
I treat interviews as a two-way conversation. The company evaluates you, but you should also evaluate them.
Do I actually want to work with these people?
I got the offer and I almost said no.
I was doing well at Bloomberg. I’d just landed a cross-team project that was fun and probably good for my career. I had a part-time master’s at Imperial lined up, already accepted, and the startup made it clear that doing a master’s on the side wasn’t realistic. The pace was different.
And honestly, I had never written frontend code. Was I the right engineer to work on “revolutionizing frontend tests”?
So what changed my mind?
I think of careers as a search for multipliers. A startup with 5 engineers, customers like Notion, and a problem nobody had solved, that’s an exponential trajectory, and you don’t get to step onto many of those.
I asked the CTO to walk me through the roadmap. I wanted to see the actual problems they were solving day-to-day. For most of them, there was no known solution. That was the thing. Bloomberg had been one big challenge. Meticulous looked like many of them, technical and not.
I joined.
What Meticulous does
Imagine a tool that shows you every difference your changes introduce in your app. Every snapshot, sorted and clustered. Nothing to write. Nothing to maintain. No flaky pipeline.
The good, the bad, everything caught.
That’s Meticulous.
I didn’t fully get it when I joined. I started doing frontend work and checked Meticulous after every commit. The results were… fine. I wasn’t shipping bugs. It was mostly confirming what I thought I’d just built.
Then one day Meticulous flagged that one of my changes had pushed a modal completely out of the viewport.
I had not touched that flow. I would never have caught it locally. It would have broken an important path through the app, silently, in production.
That was the moment.
You can catch regressions like that with enough manual testing. You can write tests on top of tests and chase coverage forever. But why, in a world where this tool exists? We don’t write a single line of frontend test, and our shipping speed is bounded by how fast we can write the feature itself.
We are not scared of upgrading libraries. We are not scared of sweeping refactors. We’ve rewritten entire event flows through our components without writing a single new test. (true story)
Before: 5 minutes to write a feature, 15 minutes to write and maintain its tests. Now: 5 minutes to write the feature, 1 minute to read what Meticulous shows me, ship.
This isn’t only us. We’ve recorded case studies with LaunchDarkly, Notion, and Engine, and those are a small slice of the companies switching off traditional frontend tests. The strongest signal isn’t the case studies though, it’s that engineers who used Meticulous keep bringing it into the next company they join.
Two things changed how I ship
1.** Agents:** I’ve never enjoyed writing CSS, Tailwind, or the markup soup of modern frontends. Agents do that for me now. 2.** Meticulous:** code is automated, but you still need a reliable, auditable way to know whether it works.
I think people underrate point 2.
If your only safety net is tests written by another sub-agent, or worse, by the same agent that wrote the change, you don’t really have a safety net. You have a feedback loop talking to itself. Meticulous is external. It runs the app and tells you what changed, regardless of who wrote it.
This is also where the review problem hides. New features are already long PRs. If you also have to read hundreds of lines of new tests for each one, multiplied by some review-cycle constant, you’ve made code review absurd. Cutting tests out of the loop has been the biggest review-time win we’ve found.
After almost a year
Meticulous is roughly split into a product team and a growth team. Almost half of the engineers are on product, expanding the surface area of what we cover, more frontend frameworks, and this year, end-to-end coverage that also includes backend changes.
I’m on growth. Closer to an FDE role with a twist: we help customers onboard, and onboarding regularly means hitting some frontend stack or scale problem the product doesn’t yet support and shipping the fix back into the core product. The interesting question is always the same: how do we generalise this so every Meticulous user benefits?
Each customer has a technical lead and a commercial lead. I sit close to sales, which surprised me. The problems on the commercial side are different from engineering, softer, fuzzier, but they require a lot of structured thinking and I’ve enjoyed being exposed to that.
Planning at Meticulous is short-horizon and bottom-up. A lot of what ships comes from engineers prototyping something with an agent, proving it works, and bringing it forward. We write a lot. Our Notion (one of our customers, fitting) is full of RFCs and idea docs. Writing forces the half-formed thought into a real shape, which is where the best brainstorming starts.
We try every agent stack. Some of us live in Claude Code, some in Codex, most in Cursor. We’ve productionized a few ways for agents to use Meticulous itself, so they can validate their own frontend changes against an external signal, instead of their own tests grading their own homework.
Conclusion
We’re hiring. If you’ve read this far, you might want to apply.
If your team is interested in trying Meticulous, you can book a demo.
I’ll go back to work now, so that when you do try it, the experience is as good as we can make it.
And yes, kill all your tests.