Four days of my week go into Intrinsiqq, a stock analysis platform I am building. The fifth day goes to client dashboard work. Power BI when that is the right tool, a web app when it is not.
That split is the whole reason my stack looks the way it does. I am not optimising for the most flexible setup or the most impressive one. I am optimising for something I can hand over and then not think about, because on Tuesday I need my head back in my own product.
Everything below follows from that.
The rule is: nothing I have to maintain
A day a week means I cannot be the person who gets paged. I cannot run infrastructure. I cannot write auth and then spend three months patching it. If a choice creates a thing I have to keep watching, it is the wrong choice regardless of how good it is.
This rules out a lot that developers with more time would reasonably pick. Self hosted Postgres. Custom login. Anything involving a container. All fine if you have the hours. I do not.
What is left is three managed services.
Next.js, Supabase, Vercel
Next.js for the app. Supabase for the data and the login. Vercel for hosting.
No Docker, no warehouse, no separate auth provider. Signed contract to a live URL the client can open in a day, and most of that day goes on questions rather than code.
Each piece removes a decision I used to have to make.
Supabase answers the objection people raise first
When I say I built a dashboard outside a BI tool, the reply is usually about security. How do you stop client A seeing client B's numbers.
Supabase is Postgres, and row level security is a Postgres feature. You write one policy saying a user only reads rows matching their own company id, and the database enforces it on every query from then on. You cannot forget it in a component. You cannot leak it through a filter you wrote badly at the end of a long day.
That last part is why I trust it. It is not that I am careful. It is that being careless does not work.
The login is the same story. I have not written a login screen in years. Supabase does magic links, so someone types an email, clicks a link, and they are in. No passwords, which means no password reset tickets arriving on a day I am not doing client work.
Server components mean no keys in the browser
The query runs on the server and the browser gets finished HTML with numbers already in it. Connection details stay on Vercel. There is no key sitting in a file on someone's laptop, because there is no key in the page at all.
The side effect is that it holds up on bad connections. A tablet on warehouse wifi shows numbers instead of a spinner waiting on three requests.
Preview URLs are the part I underestimated
Every branch gets its own URL. I send that link and the client opens the real thing on their own phone. Not a screenshot, not a recording.
The feedback changed straight away. People who say "looks good" to a screenshot will tell you the truth once they have tapped through it and found the number they wanted is three scrolls down.
It also ends a particular kind of argument. When someone says a chart is wrong, I open last week's preview and we look at what actually changed.
The same skeleton, every time
The other thing a single day forces is repetition. I start every build from the same project structure. Same auth flow, same folder layout, same handful of chart components I have already argued with once.
The first build of anything is slow. The fifth is not, and that is the only reason a day is enough. If I were picking a different stack for every client because it suited that project slightly better, I would never finish one.
Boring and repeated beats optimal and new when you only get Mondays.
The part that actually takes the time
Not the code. The code stopped being the hard part a while ago.
What takes the time is deciding which numbers go on the screen. Ask six people in a business what belongs on the dashboard and you get thirty metrics, all of them defensible. Build all thirty and nobody opens it twice.
This is the one place where spending most of my week on a data product pays off for client work. I have spent years arguing with myself about which numbers belong on a screen and which ones just look busy, on a product where getting it wrong means users leave. That transfers directly. I wrote up how I pick in this guide, framed around Power BI but none of it is tool specific.
So the order never changes. Agree the metrics on paper. Build the tables to match. Then open the editor.
What it costs to run
Both Vercel and Supabase have free tiers that genuinely cover a small internal dashboard. When a client outgrows them, the paid tiers are somewhere around twenty to twenty five dollars a month each. Call it fifty a month for something serving a few hundred users.
Set that against per user Power BI licensing for an external customer base and the comparison stops being interesting. Licensing is usually what pushes a project this way to begin with. If you want the full picture of what a dashboard costs to build and run, I broke it down here.
When I say no
Often, and the one day rule is usually why.
If the client already has Power BI and people who know it, a second tool is a gift to nobody. They will maintain it badly once I am gone.
If the real problem is that data lives in six systems and nobody agrees what a customer is, the dashboard is not the project. The model is.
If twenty people each want to slice the data their own way, they want self service, and a fixed page disappoints all twenty.
And if it needs someone watching it, I say no outright. That is a fair thing to want and I am the wrong person to sell it to you.
What is left is a narrow shape. External users, fixed questions, has to match a brand, has to have a login, cannot cost a licence per head. That shape comes up more than I expected.
Most of my week goes into Intrinsiqq, a stock analysis platform. The rest goes into dashboard work at flippielabs.com.
Curious whether people running something similar went Supabase or rolled their own Postgres. I keep waiting to outgrow it and have not yet.
Top comments (1)
Optimising strictly for zero maintenance is the only sustainable way to handle part-time client work. The Next.js and Supabase combo is perfect here, especially since Server Components let you fetch directly from Postgres without writing any messy client-side state for the dashboard widgets. The hidden advantage is the actual handoff, as transferring a Vercel project and a Supabase org to a client's own billing account takes five minutes and requires zero DevOps training on their end.