They forwarded two proposals for the same login. One named Next.js, Postgres, and Stripe. The other named Kubernetes and microservices, so they wouldn't have to rebuild. Should you pick a SaaS tech stack before you hire? I threw the second PDF out.
A tech stack is the tools the product is built with. I build SaaS and web productsonce you've already decided to build. Who types, and who holds the keys, is what to ask before you hire. If the email says they need someone senior to choose the tools, that's a fractional CTO or a freelance developer. That person still has to write the product.
Which SaaS tech stack calls are yours
Yours
What you approve
- One app one person can ship and keep up on Tuesday
- Logins, payments, and email stay on a vendor you pay
- They have already shipped this stack on a live URL
The hire's
What they pick
- Which language
- Which framework
- Which database
The cut
The first PDF was one app, with Stripe on the card and one database. A person could ship it and still answer email in October. Next.js and Postgres were names they already work in. I left the names alone. I don't love every stack I approve. The same person still has to run it on a Tuesday.
One app one person can run
Kubernetes runs a lot of separate programs. Someone has to keep those programs up, and that someone is usually a team. Microservices means you cut the product into those programs on purpose. This brief was one hire. Nobody had logged in. I want one deploy. When a booking sticks, there's one log. The second PDF had already split that job into services.
Logins, payments, and email
Stripe takes the money. A login product holds the password. Email sends the receipt. You already pay for those, or you should. I connect them. Some proposals want a login you own, a box with your name on it. That login is still unwritten in week six. The customer is waiting on a booking.
A live URL on that stack
If I can open a product they already shipped on that stack, the language is theirs. I want the URL. The logo in the footer of the PDF doesn't count. A stack they read about last month means you're paying them to learn it. What one person owns includes the deploy. Selected work is there so you can open something that still runs.
Can you change a SaaS tech stack later?
You can change the framework. I've done it. The pages still loaded. The user table doesn't move like that. The login vendor doesn't either. Payments don't. People circle React or Vue because those are the words in the PDF. Two years later the table is what they still have.
Move the buttons and the booking is still there. Move the user record and I have to rewrite every screen that read it, then the export. If a charge lands twice, you won't know which copy of the user got it. A wrong login vendor means every person who can sign in has to move. That's its own project. It won't be the week you set aside for a feature.
Payments sit in more places than the PDF admits. The charge, a failed card, the receipt. I hook those up at the start. Pulling them out later means opening every screen that takes money. I say this before the deposit. After the first paying customer it's a migration. Founders stall on the framework because they're scared the choice is permanent. The framework is the piece I can replace. A second architecture in the first invoice doesn't make the user table easier to move.
The record is what sticks
The records I want first are the booking, the invoice, and the file that's still theirs when they come back. Rows. A normal database holds them. I pick something else when a row can't store the actual thing. Hasn't been the case on a first version I've shipped. A PDF that says the other database scales is guessing at traffic that isn't there yet. Who owns the product after launch is still Tuesday. Someone has to hold the keys.
What to reject in a SaaS tech stack proposal
Nobody is using the product yet. The second PDF is already hiring a team to run it.
Kubernetes and microservices
Their line was "so we can scale." I asked scale to what. They didn't have a number. They didn't have one person who had finished the job. I've watched that setup take the month the first screen should have shipped. One app is enough to learn whether anyone comes back.
Two languages in one hire
Two languages for one person means two codebases. Python on the API, TypeScript on the site, and the broken part is the request between them. They're fast in one of those. I tell them to ship the language already running in production. The second language is on the page so the proposal looks finished.
A second database
One database, so the booking and the invoice can't disagree. A second one waits until I've seen a reason on their data. Search that's slow. Files that aren't rows. "We'll need it later" is a sync bug you pay for before the first login. I add the second store when the first one is why Tuesday is bad.
So you don't have to rebuild
That sentence bills you for year three before anyone has logged in. You'll rebuild the guesses that were wrong. What belongs in a first versionalready cuts the platform you don't have the users for. Kubernetes so you never have to start over is the PDF I don't take.
I'd rather lose the invoice than staff a cluster for a login nobody has used.
Send both PDFs. Once I know it's one app, the price is how much a web product costs. Send me the proposals before the deposit goes out on the Kubernetes one.
