I built vehicleexpirytracker.com without any engineers, in just under 2 weeks, all with AI. It’s a fully fledged B2B SaaS that helps small businesses in the UK keep track of their commercial vehicle certificates. Things like Road Tax, MOT, Insurance and so on.
I built this entirely with Cursor, and spent $75 in the process. Before this, I’d never written a line of code in my life or career.
As someone from a Product & Design background, I’ve managed to:
- Build a fully functional SaaS product, with authentication, payments and email alerts set up
- Solve a genuine problem for small businesses that use vehicles for commercial operations (cleaning companies, estate agents)
- Build databases on Supabase while spending $0 of compute
- Turned a Vercel NextJS template into a Landing Page
- Set up payments using Stripe webhooks
- Created Supabase Edge functions to automate email alerts
- Spent $40 on Google Ad spend to generate 72 clicks
- And more….
I have a lot of product knowledge from my 8 years of building B2B SaaS apps, but I am a novice when it comes to software development.
With the state of AI tools in 2025, you give me Cursor, and I’ll probably blow your mind very quickly.
The following paragraphs will break down how I started from nothing and built everything around vehicleexpirytracker.com, all using 100% AI-generated code.
Things I dreamt of as a designer (like not working with any engineers) are now a reality. I hope this inspires many more Designers to become Product builders.
Ideation is dead, long live AI.
The stack
Let’s start by explaining the stack I used while building all of this:
- IDE — Cursor, agent mode, Claude 3.5 sonnet (So far it seems 3.7 is not the upgrade from a coding perspective many anticipated)
- Database & Functions — Supabase, edge functions
- Landing page & UI — Vercel template, NextJS, Shadcn
- Deployment — Vercel & Github
- Email Alerts — Resend API
- Domain purchase — GoDaddy
- Screen recordings — Hotjar
- Analytics — Mixpanel / Vercel
- (Optional) Product Manager — GPT 4o, PRD writing
The costs ($32/mo total)
- Cursor — $16/month (annual plan)
- Supabase — $0/month (free tier, <50K users)
- Godaddy Domain — $10/year
- Microsoft Business — $6/mo
- Resend API — $0/momth
- Vercel — $0/month
- Hotjar — $0/month
- Mixpanel — $0/month
- Google Ads — $35
Disclaimer: many of the $0/month products do start charging when you get to a certain # of users, which is fine as you’ll be making money by then.
Let’s break down the key stages of building the product. I’d recommend diving into whichever one is most useful for you to read. As Nassim Taleb says, the true judgement of a book is by your ability to go to any page at any time and find value.
Article chapters:
- Boomer business problem hunting
- Building the MVP
- Creating project context & setting up databases
- Vercel & Cursor setup
- Head scratching bugs & phoning my engineer friends
- APIs, webhooks and edge functions
- YouTube AI walkthroughs
- Building multi-tenancy & auth
- Running Google Ads
- User feedback & iterations
- Kent small business research
- Future of the project
1. Boomer business problem hunting
Armed with Databutton as my AI agent, I got on the phone to my auntie, who runs a cleaning company for private schools in Kent. Their business, Kent Gurkha, is like many other ‘boomer businesses’, profitable but not tech-savvy.
I sat with them one morning, and asked them to tell me what costs them the most in the following areas:
- Time
- Money
- Stress
Whilst it became clear that they needed generally more tech automations, one interesting problem stood out.
Their commercial vehicles.
Whilst their main service was cleaning the actual school, they needed to transport staff to various locations across Kent. Managing these vehicles became a pesky task for the team, one that was littered across spreadsheets with no structure, maintenance or even formatting.
Commercial vehicles in the UK have legal requirements that go beyond those you and I might have. The usual MOT, Road Tax and Insurance applies to every vehicle. But for commercial use, and those with vans in particular, there is a 10-weekly PMI and Tacograph check.
5 certificates, over 6 vehicles, and 30 different dates to keep a track of.
If they weren’t maintained, the fines were potentially unlimited (e.g. in the case of insurance).
It has a good mix of annoying problems I don’t want to deal with as a business owner, and something I have no choice but to legally do.
There were plenty of fleet tracking solutions in the market, but most targeted enterprise size businesses, or ones where vehicles were a core part of the business (e.g. trucking). There seemed to be a gap for the non-vehicle focused businesses that had to have vehicles.
It was the perfect breeding ground for a B2B SaaS product.
I decided there and then to create a centralised portal for them to manage their vehicles (and employees and clients too). This would be online, and not require them to manually go in and find out what certificates had expired, they’d either be alerted, or it would be clearly shown to them.
2. Building the MVP
I cracked open a new project on Databutton, and started to build out the platform. At first, I took their raw Excel files, cleaned them up with Cursor into a JSON file (because that’s what I thought was the right ‘technical’ thing to do), and got Databutton to ingest & read the certificate dates.
The product itself was quite simple. Users would upload whatever data they had stored already in any format. I’d clean it up using custom Python scripts with Cursor, and then the app would read the more standardised JSON file.
Being a complete beginner, I did not think of any databases or proper stores of information. Instead of opting for whatever came to my head first. I quickly realised this was a mistake, and while I did manage to spin up the MVP in about 4 hours of prompting, I ran into plenty of bugs thereafter, which I knew meant it was time to do this properly.
My auntie was using the product, but it needed to be more robust, if it was going to be used by many more.
3. Creating project context & setting up databases
Whilst I was bubbling under the excitement of building a product by myself, I was keeping a keen eye on what was happening on Twitter.
I’d started to see how PRD writing was trending, with people using GPT to help them write out extensive PRDs for projects they were working on. Some would even just dictate with voice, and get GPT to create a clear document borne from their word vomit session.
This sounded all very serious, and so I then proceeded to ask my real engineer friends how I would go about creating this app ‘properly’.
They gave me two key elements that helped me speed up the creation of this:
- Supabase
- Vercel templates
I set up Supabase as my database, to properly store the data that I had converted from Excel files to JSON. I spend a bit of time converting the data I had in Excel into a proper database table, constructed from 3 fundamental tables linking vehicles, the different certificate types and updates over time (an audit trail was needed for legal purposes).
The schema became the following:
I’d accidentally set up my ID’s for each table in number format instead of UUID, which was a lesson that my more pedantic engineering friends relished in teaching me…
To try to make this process as automated as possible, I got access to the DVLA API which would let me query the UK database based on registration number and get almost all the fixed data regarding a vehicle.
This data also included MOT & Road Tax dates, meaning that 2/6 certificates wouldn’t need to be entered by users, reducing 33% of the friction in using the product.
The API data would later come in handy to ensure updates were fed through to the app on an ongoing basis.
4. Vercel & Cursor setup
Now that we had the database set up, next was to actually create a front end for the app. This was when I had to start getting my hands dirty with Cursor.
I took the Admin dashboard template from Vercel’s template library, and cloned the project into my GitHub repository. I did not know what most of these terms meant, but every time I asked Cursor or GPT to explain it like I’m 5 years old. This was a very fun way to learn technical things without getting overwhelmed.
I then prompted GPT with a giant dump of the purpose of this project. How it had come to be, what it was trying to solve, and how to approach this whole thing. This then led to the creation of a giant project context file, which alongside some dedicated PRDs for new features, would be the flow in which I would start to build out functionality.
Cursor was also great for building things the right way. After enough times being reminded that ‘my API keys should be stored in a secure place’ I created a .env.local file that kept things secure.
When I was building out things that had multiple nuanced steps (e.g. taking data from a new vehicle modal, creating an entry in the vehicles table, then using that vehicle ID to create certificate updates on another table, and then sending a toast notification to the user) it would set up logs to see what stages were succesful, and what failed.
This made debugging with Chrome, which has its own AI explanation in the inspect console, much easier. MCP’s have been trending recently on Twitter, which is supposedly akin to each program you have on your machine having an API and talking to each other, and I look forward to testing that out between Cursor & Chrome, especially for debugging.
I’d ask Cursor for anything. I didn’t understand certain terminal outputs after running some commands, so I’d ask it to translate, or output in a dedicated file. The Vercel template I’d set up with was configured to have Drizzle as the ORM, but as I was using Supabase, I needed to change it, so I asked Cursor to look through my codebase and update what needed to be updated.
Claude’s Sonnet 3.5 was highly competent in most tasks. I did run into some classic issues and there were plenty of whack-a-mole moments that made me want to get a shotgun and annihilate my laptop.
5. Head scratching bugs & phoning my engineer friends
Cursor, Claude, whatever AI model or tool or agent you use, will not be perfect. Far from it. The best usage I’ve found with AI is a directive-approach. If you ask to go on a goose chase on Composer mode without much guidance, you will end up with 0 credits remaining and nothing to show for it.
Whilst I didn’t know everything about building a properly functional SaaS, I set up a limiter in my head. If I couldn’t crack the issue with Cursor in 4 goes, I’d drop a note to one of my many engineering friends (so as to not dominate one to the point of resentment).
I ran into problems like the following:
- Middleware being too restrictive, and went into a block-first approach, rather than an allow-first approach
- HandleAdd functions and schema mismatches in my modals, where Cursor would wipe functions that previously worked, and ignore the schema I’d meticulously detailed out
It ended up getting so bad I created a whole ‘Whackamole bugs’ folder that stored all the issues we repeatedly faced and exactly how we solved it, so it could be avoided.
Ultimately I could solve all of these problems through a mixture of AI models, but sometimes just asking someone who’s done the thing before is 5x faster and 10x less traumatic.
This was one of the major limitations of Cursor the first time building something. Because I had no clue how exactly some things needed to be built or what exactly was needed, Cursor would vibe itself through as if it was throwing spaghetti at the wall. When most of it didn’t stick, and that’s when I brought in the proper chefs to teach me how to make the pasta the way I really needed it to be.
6. APIs, webhooks and edge functions
I’m now convinced the entire internet is just API wrappers, and boy are they fun.
As I now started to get the app working properly, I began to introduce more exotic functionality.
Things like email alerts, automatic number plate updates and even receiving payments were on the list.
This was when I started to embark on connecting APIs, setting up webhooks and Supabase edge functions. Once again, I did not know what any of these things meant or actually did, but Cursor, GPT and some of my engineering friends came to the rescue.
It was surprising how easy it was to get things set up when you read through the developer documentation that existed for products like Stripe & Supabase.
To set up the daily DVLA API refresh [update-vehicle-dvla-data], I needed a cron job to run every day at 1 AM, and update the vehicles table in Supabase. This became an edge function that ran and was setup with the help of Docker, and would ensure that the data a user saw would be fresh every time they came on the app, not just the first time.
To set up a connection from my Stripe payment page [stripe-payment-success] to a webhook that would populate the [users] table in Supabase was a breeze considering it was the first time creating it. It really makes you appreciate how easy these excellent products have made the set up experience, and in turn why they’re so successful.
To set up email alerts [check-expiring-certificates], to alert users on a weekly basis when their vehicles are coming up to expiry, I used Resend API through Supabase, and again, it was a relative breeze, as soon as I had my own email (info@vehicleexpirytracker.com).
When I would test the robustness of these APIs, and see my users table populate with ‘subscribed’ or see the email get sent alerting a user to an expiring certificate with my 30 day logic, I got an unbelievable high. As a designer, it was wild to see something I had built myself, work end to end.
7. YouTube AI walkthroughs
A special shoutout has to go to the weekly livestream from This Week in Design, and Greg Isenberg, who brings on great hosts that built things in smart ways.
These two below were particularly inspiring and helped me tactically build the app:
The vast level of knowledge that’s shared on Twitter is truly awe-inspiring, and has helped build a huge level of personal motivation to get sh*t done.
8. Building multi-tenancy & auth
One of the more nuanced parts of the experience was building multi-tenancy authentication, to allow many businesses to use VET, while being hosted on the same database tables.
Regular auth was done through Supabase, which has a fairly easy setup (again if you follow the developer documentation).
I had the slight nuance of Kent Gurkha, (my auntie’s cleaning company) who needed access to a few parts of the app that the rest of the market. As I’d built a centralised portal for them initially, and then spun up the VET idea after, I had employees and clients pages that existed in the app, but didn’t need to be accessed by any other users.
I proceeded to create a mixture of a user flow and service blueprint, by combining what was happening in Supabase with what I needed to happen on the UI.
I then fed this into Cursor, alongside a PRD and basically one-shotted the entire experience. It built it 90% correctly the first time, which was fantastic, and showed progress.
For future PRDs, I began to create sequence diagrams that were even better at articulating these flows, the only downside being that you’d have to make a sequence for each distinct user flow. The upside is that you don’t need these messy legends of green and blue boxes.
The app was now running and live. When I tested the new user sign up flow end to end, I got a rush unlike anything before. Seeing the possibility of a stranger entering their email, and accessing the app I’d built, at any time of day and then paying me gave me more confidence than the hottest girl in class coming up to ask me to prom.
9. Running Google Ads
As I finished up the final touches of the core app functionality, I met with a friend of mine, Emory, who’s built multiple products with Cursor and with AI built in. He’d created roadtrip.app and Kuraplan, an AI lesson planning tool for teachers.
I gave him the rundown of what I’d built and he nonchalantly told me to launch some ads and see what the market had to say. I hadn’t planned for this to be a B2C app, and expected a lot of the B2B to come through referrals and cold email. But the idea of launching ads, somethign again that I’d never done, seemed like a good idea.
I started with Google Ads as I knew there was some level of traffic around MOT searches and fleet management that would exist on Google search.
Whilst Google Ads is one of the biggest products on the planet, it is a complete Frankenstein of a product that is near impossible to use without some guidance.
I started with Performance Max campaign and started testing out some keywords and ads, copied or very similar to competitors and other best in class apps I’d seen while searching on Google.
At this time, I was reading ‘Getting Everything You Can Out Of All You’ve Got’ from Jay Abraham (an internet marketing god), and applied one of the learnings from his ‘Clients’ chapter.
He spoke about how the difference between Clients & Customers is how Clients are under your protection, and you are serving them under your guard. I realised that my guard & protection was ultimately avoiding hefty fines.
That was the real value-add and outcome that I wanted to communicate and felt would resonate most. Due to the legal requirement of these certificates, it made sense that avoiding fines, especially when vehicles weren’t a core part of your business, would resonate.
On my Google Ads, the best performing ad was relating to ‘Avoiding fines’ (48 clicks, 20% CTR, £0.07 CPC) and the best performing keyword was ‘Road tax reminder’ (12% CTR, £2 CPC).
Jay Abraham also says to ‘test small’ and so in under £30 of Ad spend, I managed to generate 100 clicks to the site, with a CPC of 28 pence, which was great performance.
The funnel then went onto the landing page, then onto sign up, and then Stripe payment.
Of the 100 clicks, 7 signed up to create an account, but none converted to paying subscribers.
I then started to iterate and research more, to get that elusive first paying customer.
10. User feedback & iterations
I’d set up Hotjar to see how customers were using the site, and was surprised to see lots of reading through the site and its functionality.
I then decided to create some iterations off the back of what I’d seen:
- Users not confirming their email address — I’d left my authentication email to be sent from Supabase instead of through my actual domain, which must’ve put off users from confirming from a provider they hadn’t yet heard of
- Users dropping off at email creation — I added Sign in with Google to reduce the need to create through email, and also confirm after
- Users seeing a generic landing page after clicking on an ad — I created an MOT-specific landing page vehicleexpirytracker.com/mot-landing which had targeted messaging that continued the journey from the ad they had seen.
- Users not converting to paying subscribers — I changed the offer to be a one-time fee, instead of a monthly subscription, as I expected those that were searching for this type of product to be doing it on an annual basis (which is how typically the consumer focused certificates like MOT expire), instead of a monthly fee. This required changing the Stripe payment link and product, which, thanks to it being just a URL, wasn’t too difficult a process.
All these iterations were done over time as traffic to the site grew, but we still missed that elusive customer. I went on a spree to do some more research to understand exactly why, landing on a key insight that brought me to a key decision on the entire app.
11. Kent small business research
As I was targeting the B2B space, I started to reach out to various companies that would have vehicles. I cold emailed Taxi Companies I found from a Taxi Summit Conference. I went to farms across Kent to ask how they managed this very problem.
As I went through this process, I visited over a dozen businesses and was surprised by the findings. I went to their offices, knocked on the door and asked them if they’d be open to speaking for a few minutes.
Those that had vehicles at the core of their business, no matter how ‘Boomer’ they might be, would always have a dedicated tech solution they used. One particular farm had an administrator who would put the MOT & Road Tax dates on a whiteboard, whilst simultaneously using Ramtracking.com. This surprised me, but after speaking with my friend Tim, he said something that stuck with me.
It sounds like these people are going for a safe option. It’s like the how no one gets fired for picking IBM thing.
I even heard one administrator I spoke with say how they’ve been using Fleetcheck because they wouldn’t use ‘any old thing off the street’.
It started to become clear that I was fighting against the assurance and security that came with incumbents. A battle that I was never going to win.
12. Future of the project
Through this research and the lack of conversions into paying customers, I decided to park the project.
My auntie continues to use the product, and perhaps a referral from her will help another similar company. But for now, I decided to move on to tackle a problem that has a few other elements:
- Actual AI in the solution — while I built VET using AI, it didn’t have any AI-powered features like auto-MOT booking that I’d dreamt of
- An experience ripe for AI transformation — It would be a shame not to do so in the gold rush we’re in
- Limited number of incumbents — It’s hard to compete with longevity, and this combined with point 2 is a powerful recipe for success
I did meet with a B2C counterpart in the space, Bhavin, who founded Caura (fantastic product), and went through some of the above learnings. We met in person too and I gave them some pointers on how to leverage AI more in their space.
I firmly believe there’s room to optimise the car management process, and things like insurance, MOT appointments and servicing bookings can be optimised using AI quite well.
Closing
This project taught me a tremendous amount about Product. So much so that I think every Designer and Product Manager and Developer should try building a product end to end to see what it’s actually like to build.
I guarantee it will turn all those ‘Why do we need to build this and in this way’ type of questions will evaporate as you dive into the nuances of design and engineering. Combine that with a healthy peppering of pragmatism as you operate in a pre-PMF market with limited/no budget, then you start understanding exactly why the decisions that are often made in product, are made.
I’d love to engage with other builders in the space, so if you found this article valuable or interesting, share it with someone, or on your social profiles!
Email me at Pegasus.dco@gmail.com!
Extra: The story behind how I started
In December of 2024, I received an email from Viral Shah of Databutton, asking me if I’d be interested in creating some content for their product, an AI agent he’d co-founded with a few of his Norwegian friends.
The product intrigued me. Not only due to agentic products trending right now, but also due to him being able to guide me deeply through the experience of this particular agent. A deep-dive from the very person that helped to build it. Doesn’t get much better than that.
I tested the product while we were together on the call, and I got a feeling that something interesting was bubbling. Of course I was interested in creating content for the product, but what really piqued my interest was what I could do with the product itself.
I left that call with a feeling deep down that I need to dig deeper into this, and properly play around.
Since then, life has not been the same. I’ve learnt things that I’d heard only developers speak about, and I’ve built things I never thought possible. All as someone who comes from a Product Design background.
