How I Built My Vision Assistant: A SaaS for a Client, Start to Finish

My Vision Assistant is an AI content-marketing SaaS that I built as the sole engineer for a client, My Vision Agency. This post is how I approached it: the stack, the decisions that mattered, and what I'd tell anyone building a SaaS for a client.
The short version: React and TypeScript on the front end, Supabase on the back end, and one person owning everything from architecture to releases. That meant fewer hand-offs and faster decisions, and it also meant owning every problem when it appeared.
I've kept this at the level I can share. Client data, numbers and anything private are left out.
What the client needed
An AI content-marketing product that members could log into and use to create marketing content. I came in as the only engineer, so the brief covered everything: the product itself, the back end, and keeping it running once people were using it.
The stack I chose
React and TypeScript for the front end, because a typed codebase is easier to change safely when you're the one person who knows all of it. Supabase for the back end, which gives you a database, authentication and serverless functions without running servers for them.
For hosting and releases I lean on the same tools as the rest of my client work: Linux on AWS, Docker, Nginx and Cloudflare. I choose boring, well-understood tools on purpose, because one person has to be able to run all of it.
Multi-tenant from the first table
A SaaS serves many customers from one product, so my rule on any multi-tenant build is to treat separation between accounts as a design rule from day one, not a patch later. Every record belongs to an account, and the back end decides who can see what instead of trusting the screen.
Adding AI, and paying for it
AI features cost money on every call, so they need metering. My Vision Assistant uses credits for AI use. One of the bugs I fixed was double billing, where a single AI action charged credits twice.
The lesson is that billing code deserves the same care as payments code. Charge once, record every charge, and be able to explain any balance to a customer.
Opening the product to Claude with MCP
I shipped an MCP server so members can use the app from Claude. Instead of only clicking through screens, a member can ask Claude to do the work, and Claude calls the app's tools on their behalf.
It's the same idea I now use in my own product, OwnMyCRM: build the product so that people and AI agents can both drive it.
Releases and quality
As the only engineer I can't count on a second pair of eyes, so I rely on process instead: Cypress end-to-end tests for the journeys that matter, and staged releases so a change reaches a few people before it reaches everyone.
What I'd tell anyone building a SaaS for a client
- Agree what "done" means for the first release, and ship that before adding anything.
- Make money-related code boring and well tested, especially credits and billing.
- Design for many customers from the first table you create.
- Keep hosting simple enough that one person can run it.
- Write down how things work, because one day the client will ask you to hand it over.
- Tell the client about problems early, with the fix attached.
Working as the only engineer
The upside is speed and one consistent design, with no hand-offs to get lost in. The cost is that nobody covers for you, so documentation, monitoring and simple infrastructure matter more than clever code.
Questions people ask
How long does it take to build a SaaS like this?
It depends on the scope. A focused first release takes weeks, not days, and the product keeps growing after launch. I'd rather agree a small first version with you and ship it.
Do I need a whole team to start?
No. One engineer who owns the whole product can move fast. A team becomes useful once the product and the customer list grow.
Can my product work with Claude?
Yes. An MCP server lets Claude, Cursor and other agents use your app's tools. I've shipped one for My Vision Assistant and use the same approach in OwnMyCRM.
Why Supabase?
It gives you a Postgres database, authentication and serverless functions in one service, which keeps a small project small.
Can you build one for me?
Possibly. Tell me what the product has to do and who it's for, and I'll tell you honestly how I would build it.
Have a SaaS idea or a product that needs an engineer? Email me for a free 15-minute call.
