How We Built BIMP
What did we learn building at the speed of AI?
This blog post will disappoint some of you. Hopefully it will also inspire some of you.
BIMP was not vibe coded.
BIMP was not built by a swarm of autonomous agents.
BIMP was built by us, Hannah Foxwell and Stuart Preston. Two smart people and some AI tools.
This post aims to condense some of the things we learned through this process.
Reimagining Product Development
We started this project with two goals:
Build something worth building
Build at the speed of AI
We wanted to move quickly but even we were surprised by the speed we were able to build.
Over morning coffee we chat about what we have planned for the day, then we do those things. We introduced as little process as possible.
There was no roadmap, no backlog, no stories, no tickets. We aligned on our plans for the day, made decisions about scope and discussed implementation options. Our discussion was transcribed and documented for us by our custom AI tools.
On the first day of the BIMP build we smashed through our goals for the day in a couple of hours. We were able to authenticate using google, we’d built a GitHub app, connected BIMP to a GitHub organisation, selected a repo, scanned a repo for Dockerfiles and opened a pull request on the Dockerfile in that repo.
The same happened on day two. We wanted to create a policy file that dictated what the FROM: line in the Dockerfile should say and open a Pull Request to replace the current base image with an updated base image.
If you want to learn more about what BIMP actually does you can read more in the post “What is BIMP?”
Hannah received a video demo from Stuart at 12pm while standing on the train station platform in York. Job done by lunchtime. Is this… is this… an MVP?!
On days like that you start to dream about a future where you can log off at lunchtime every day. What would life look like if we made a choice to organise ourselves in that way? What if we set a goal for the day, deliver it, and logged off?
What we learned
A two week sprint is insanity in 2026, a day of work for one developer was hard enough to scope
Many of the practices we use to manage priorities are redundant - tickets, backlogs, user story maps etc. It’s more important to identify dependencies and work through the tasks in a logical order
We learned to be ambitious and aim higher. We might have delivered an MVP in 2 days but we didn’t stop at an MVP, we wanted to deliver a MEP “Minimal Enterprise Product”
User Empathy Is Everything
Building is only fast if you know what you need to build. Luckily both Hannah and Stuart have spent their careers building enterprise platforms and driving technology transformation.
It is what we do. We are very good at it.
The difference this makes to velocity can’t be underestimated. Instead of waiting for user research or beta testers both of us understood the users’ needs instinctively.
“No, this will piss off everyone involved, we need to make this invisible.”
Despite this we didn’t want to blindly trust our assumptions. Hannah conducted user interviews with real people with real problems (I’m sorry you’re stuck on Node 8 dude). This revealed our blind spots and immediately made the product better.
Based on our user research we added two new personas to our product. The Engineering Director who wants to know how their team is doing and the AI Agent who wants to deliver work reliably but doesn’t know the organisation policy.
What can you do
Consider moving your engineers closer to users, whether that be in partnership with product or with support teams. Forward Deployed Engineers and Product Engineers are becoming popular for a reason!
Forget the “ship and switch”. This is the practice where teams ship v1 of a feature and move to the next. Feedback and iteration with real users is gold dust and turns a product from a nice idea to something that people love.
Prioritise visibility and distribution before you need it. On day 2 of the project Hannah started outreach, uncomfortably early for Stuart. We launch the product today with a healthy waitlist of potential customers - talking to them will help us improve and we’ll get better faster regardless of whether they decide to buy.
Create The Tools You Need As You Need Them
We are bootstrapping. That means we don’t want to splurge on tools before we’ve tested our ideas.
Keeping things lean we have started to build the tools we need as we need them. We built an assistant called Otis who listens to our meetings, provides summaries and learns about our company over time - offering insights and reminding us about tasks.
Otis is our wise owl. We love him.
His insights include:
“The Hoot” - the headlines of the day
“The Perch” - key topics covered
“The Hunt” - Action Items
“Otis’s Insights” - A reflection on how things are going
“The Screech” - Otis reminding us to do things
Our assistant Otis has so much potential to help us streamline our operation. We will continue to evolve our internal toolkit with personality, flare and fun.
“My head is exploding with ideas and things I want to build. It’s like every project leads to more ideas and more projects … and I can try them out in just a couple of hours on the sofa. I can’t stop!”
Work should be joyful and we have an opportunity to create a work life that is whimsical and fun.
A whimsical and fun cyber security company. What a thing that would be.
Building Has Never Been More Fun
We have had so much fun building BIMP. Building has never been so much fun.
Sure, it would be nice if we found some users, it would be even nicer if BIMP made the world more secure. What a thing that would be. But we’re not interested if it’s not fun. We’re not interested if it’s not joyful.
Our home page has a 3D model of a blimp souring in a 3D space. This was not required but it was bloody fun.
What a time to be alive. Get building. That’s it.