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.” - Hannah

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!” - Stuart

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.

Say hello to BIMP!

BIMP is a Base Image Management Platform. It’s a platform that you can use to manage your base images. Simple right? So why hasn’t anyone built this before?

If you’re building your applications as containers then you will no doubt be familiar with the Dockerfile. Imperfect as they are, they are the default format for building container images. The Dockerfile includes the configuration for the containers base image - the base layer on top of which you add your application and its dependencies.

The FROM: line in your Dockerfile is one of the most important interfaces of your software supply chain. The base image you select in that FROM: line is the gateway through which reams of Open Source Software enters your organisation. If any one of those packages is vulnerable your container is vulnerable.

Most companies have a policy here, they want developers to build their containers from a secure base image, a base image procured from a reputable supplier who provides SLAs and commitments on vulnerability patches.

All you need to do is select the right base image provider for you, and then make sure every FROM: line in every Dockerfile in every repo is kept up to date continuously. It’s not enough to select a secure base image today, you must keep that base image up to date constantly to ensure all new CVEs are fixed in a timely way.

BIMP automates this process end to end, putting base image CVE remediation on auto-pilot.

BIMP does this by ingesting your approved base image catalogue and then opening a pull request on every Dockerfile in every repo automatically.

The Gap

Most teams we’ve spoken to simply don’t update their base images, leaving them more and more vulnerable over time.

The problem is not technical. Updating a single line in a single file is not difficult. A single action could remediate tens, if not hundreds, of vulnerabilities. The problem is an organisational one.

The Development Team creates a Dockerfile, selects a base image and hooks it up to their build process. That is how it remains until someone (usually security) asks them to update it.

The Security Team is overwhelmed by risk signals, including vulnerability data from their chosen container scanner. They have to triage and prioritise those risks. They know what the fix is, but to make the fix they need to track down the right team and update the right file.

And this needs to happen continuously. There were over 48k new CVEs discovered in 2025 alone.

The Platform Team is curating a Golden Image catalogue of approved base images. They have worked with Security to select the right supplier and then they may have customised those purchased images ready to be used. They have told all of the Development Teams they support where to get the images, but they don’t know if every team has complied (and they suspect that many of the images have become insecure over time).

The solution is BIMP. A Base Image Management Platform. A Platform that makes Base Image Management completely automatic.

How Does BIMP Work?

Platform

The Platform Team curates their approved base image catalog once. They set the policy in BIMP and let our platform cascade updates to every Dockerfile in every repo with a ready-to-merge pull request.

Developers

When it’s time to update their base image BIMP creates a PR on the Dockerfile. The Dev Team can simply merge and move on, never leaving their workflow.

Security

BIMP eliminates friction and puts base image remediation on autopilot. Security can be confident that all vulnerabilities discovered in the base image layer will be remediated automatically without them having to do any chasing at all. They are free to focus on other risks.

Isn’t this incredibly noisy?

There are two types of updates in BIMP - Routines and Incidents.

Routine Updates

The most popular is the routine update - as an organisation you decide how often you want teams to process routine updates. That might be every 2 weeks or every 12 weeks, it’s up to you. The point is that there is always an update coming, no one gets left behind indefinitely and no-one needs to remember anything!

Security Incidents

However, sometimes you need to patch a vulnerability with more urgency than that. BIMP has an override feature that allows Security to push immediate updates to any repo that is impacted by a newly discovered vulnerability. These are tagged as BIMP-Security-Incidents.

BIMP also gives the Development Team the opportunity to plan work on a schedule that works for them. If they can’t action a base image update immediately they can request a snooze. The snooze request is their commitment that they will do the work eventually, and security have the organisational context they need about the vulnerable base image.

BIMP reopens the pull request when the snooze expires so if ownership of the repo changes, the update isn’t forgotten.

Supply Chain Security in 2026

Agentic Hackers have arrived. Every day we see another newsworthy story of a supply chain attack or embarrassing compromise. Couple this with the tsunami of new vulnerabilities being discovered and the battle maintainers are fighting with code-slop contributions and we find most security teams in a pressure cooker.

Reviewing, triaging and prioritising risks worked when the volume of risks was small (well, smaller) and when most hackers needed years of experience to figure out novel ways to exploit vulnerabilities.

There’s a growing discomfort in security teams that ignoring the lower risks may not be a solid strategy in an age of Agentic Hackers. If there is a chink in your cyber-armor an agent will find it, and they won’t get tired of trying. Luckily, the same technology that helped create this pressure cooker can help us solve this problem.

Automation is the answer and AI unlocks huge opportunities for automation in our software development processes. Prioritisation is still important but we believe that you should fix the foundations by default. No triage, no prioritisation, no chasing - just fucking fix it.

Our Vision

We believe that action oriented security is the future. We aren’t another bad news dashboard full of risks. We start with the question “what needs to happen?” and then we automate that action end to end, so neither security or developers need to think about it.

Our vision is to secure the foundation of the software supply chain for everyone, by changing how the work gets done. Zero-CVE base images need to become the default and BIMP is going to get us there faster. Migrate in minutes not months.

Secure your container base images today. Be zero-day ready tomorrow.

Watch the demo on youtube or join the waitlist.