"We have the results — but no screen to show them on"
About three days after the last installment went up, the CEO of a manufacturing company sent me a short email: "About those 1,000 pages we digitized — is there a screen we can actually look at the results on, right from our shop floor?" I started typing a reply and my hand stopped. Operational data was clearly piling up, but we didn't yet have a dashboard that could surface it easily.
The OCR pipeline was a backend story. What sits in front of it — the screen a decision-maker touches with their finger, and the data flow behind it, carved out and lifted into place within 28 days — that's a different rhythm. In this installment, I want to tell the second half of the story I couldn't finish in the previous OCR operations log.
Why these three: Next.js, Supabase, Vercel
Let me be upfront: I didn't pick these three because they're trendy. When you work backwards from "a full-stack MVP you can hold in your hands in four weeks," this trio is what's left standing.
As of 2026, Next.js 14 is effectively the default for any new full-stack project. App Router, Server Components, Server Actions, and Middleware all sit inside a single framework, and the same codebase handles both the rendering layer (SSR/CSR) and the API layer. Just not having to maintain a separate backend repo and deploy pipeline lightens the first-week friction by a full notch.
Supabase puts auth, storage, and realtime on top of Postgres, with row-level security (RLS) baked in by default. The key isn't that it's "just a database" — it's that permissions get decided inside the database. That's the second axis of a 28-day rhythm.
Vercel finishes your CI/CD with a single line connecting a GitHub repo. A push to main is production; any other branch gets an automatic preview URL. No separate Jenkins, Docker, or Kubernetes setup needed. The flow of telling a decision-maker "take a look at this URL" at the PR stage plays a surprisingly large role.
The 28 days that built 5ya.io itself
This very site, 5ya.io, was built the same way. Middleware-driven routing across four languages (Korean, Japanese, English, Chinese), an admin for blog posts, external publications, and prospect management, contact forms, an auto image-generation pipeline — a full stack one person carved out in four weeks. That's not abstract bragging: every menu item on this site is a concrete answer to the question of what made it in and what got cut, within the 28-day window.
Week 1 — Routing and auth skeleton
Set up locale routing for ko/ja/en/zh via Middleware and build the admin login flow with Supabase Auth. The first draft of RLS policies gets sketched out at this point as well. There's almost no UI. Instead, this is the week you stand up "the frame the next three weeks won't rattle on top of."
Week 2 — Data model and RLS
Design the core tables — blog, external_posts, prospect_companies, contact_submissions — all in one go. Admin permissions get verified server-side, and from the environment variable names onward you separate things so the service_role key absolutely cannot leak into the client bundle. Spending a few extra days here is what prevents a month's worth of incidents once you're in production.
Week 3 — UI and preview iteration
For every PR, Vercel automatically emits a URL like preview-{sha}.vercel.app. This was the first project where I never had to tell an outside designer or PM "wait for the staging build." Sharing every tiny change as a URL roughly doubled the felt speed of decision-making.
Week 4 — Multilingual support and operational readiness
Week 4 is always the assortment of "small things that don't feel like they'll ever close." SEO meta, sitemap, OpenGraph images, error pages, monitoring, an RLS policy re-check. None of it is flashy, but it shapes the first impression the moment a decision-maker opens the site.
Monthly operating costs — in real numbers
This is where the decision-maker's question is almost always the same: "So how much does this cost us each month?"
Once a five-person team is fully operating, Vercel Pro starts at $20 per user per month and moves in the $100–$250 monthly range depending on traffic and compute. Once bandwidth exceeds 100GB, an extra $40 kicks in. For ordinary operations without a traffic-spiking campaign, it rarely climbs past $200.
The Supabase Pro plan starts around $25. Layer on operationally essential options like PITR (point-in-time recovery), and you're looking at $100–$200. Combined, the two run roughly KRW 300,000–600,000 per month — a not-terribly-wrong estimate for the fixed infrastructure cost of a typical MVP in its first year.
How does that compare to the Korean outsourcing market? Recent data from places like Wishket puts a simple service MVP at KRW 1–3 million; bump up the complexity and it's KRW 3–5 million or more; once you're building API servers from scratch, the range scatters from KRW 10 million all the way to KRW 80 million. The general market sense is that using a well-built BaaS like Supabase cuts backend development cost by roughly 30–50%.
Three things to know upfront about running Supabase
RLS isn't done the moment you set it up. From the perspective of nearly a year of running operations, three things trip people up most often.
First, make turning on RLS for every table in the public schema the default. If you don't write the policies into the migrations alongside the schema, at some point one or two tables will sneak in that anyone can read. Second, the service_role key must never make it into the client bundle. Separating things at the environment variable name level is the safer move. Third, columns referenced inside RLS policies absolutely need indexes. RLS without indexes is the number-one cause of "why is this so slow?" in real-world operations.
All three are the easiest items to drop within a 28-day rhythm — and the most expensive to undo once you're in production.
"Try opening this PR"
The real advantage of pairing Vercel with GitHub isn't cost — it's decision speed.
The flow I rely on most when running 5ya.io looks like this. A small copy fix, a new blog category, a new admin menu — anything. Branch off, open a PR, and Vercel automatically attaches a preview URL. Toss that URL at the decision-maker and within 30 minutes you've got either an "okay" or a "just change this one line." A separate staging build queue, designer review schedules, a deploy window for the demo — all that friction vanishes at once.
Who 28 days works for, and who it doesn't
That said, in fairness: 28 days isn't a workable rhythm for everyone. From a decision-maker's standpoint, the biggest variable is "how fast product decisions get made." Code, frankly, is the fastest part. If meetings keep getting rescheduled and decisions slip two weeks at a time, 28 days turns into 56.
The thing that helped most when building 5ya.io was that "tools for making decisions asynchronously were already in place." If your team is set up to drop preview URLs into Slack and trade opinions in the comments, four weeks is plenty. Reverse that — every decision must be made in a face-to-face meeting — and the same build stretches to eight weeks.
What's next, and a closing note
In the next installment, I'll shift the angle slightly and walk through the seven decisions a luxury D2C brand's decision-maker faces when going into a digital build — from domain strategy through payments, CRM, and inventory sync. Even the same full-stack build looks very different once you weigh which items actually need sign-off.
If you'd like to gauge whether the 28-day MVP rhythm fits your own company's idea, feel free to send a quick note via Free consultation. The first 30 minutes are no-charge, and we'll map out the full-stack scope of your current idea together — where the 28-day boundary lies, and where you'd cross into 56.