Building a SaaS is faster than it used to be. A coding agent can get you a working product in days. The part people skip is everything around that product: a second look at the code, a landing page, store screenshots if you have an app, payments, and a way to see what users do.
This is a short list of tools I would use while building, before I start outbound. It is not a framework. Pick what matches the product you are shipping.
Build the product
Review the code
Landing page
Store screenshots
Payments
Analytics
Support
Docs
Build the product
Use a coding agent to write the first version. Cursor (cursor.com) is the one I open first: the agent lives in the editor, so you can ship the signup path without leaving the repo. Claude Code (claude.com/product/claude-code) is the better pick when you want that same agent in the terminal.
For screens and landing pages, use v0 at v0.app. Generate a UI, drop it into the repo, then keep going in the coding agent. Point all three at one job: a new user can sign up and reach the main result.
The product does not need every feature. It needs one path that works for a stranger.
Review the code
The agent that wrote the change should not be the only thing that checks it. It will tell you the patch looks good. That is the writer grading its own homework.
Use Critique at critique.sh. It is an independent code-review CLI. It reviews the code on your machine before you commit, including staged and unstaged changes. Your coding agent stays in the lead. Critique reconstructs the change and comes back with evidence, not a vibe.
Install it, connect it to the agents you already use, and run a finish pass against the thing you are about to sell:
npm install --global @critiquedotsh/cli
critique login
critique integrate --agent all
critique finish --intent "A new user can sign up, pay once, and reach the core result" --repair pack --jsonYou do not need a long review ritual. You need a second opinion on auth, billing, and anything that can run twice. Start at critique.sh.
Landing page and copy
Before outbound, you need a page that states who the product is for and what happens after they sign up. v0 at v0.app can draft that page. For the words on it, use Claude (claude.ai) or ChatGPT (chatgpt.com). Both are good. Pick the one you already have open.
Keep the page to a few things:
- Who it is for.
- The result they get.
- One screenshot or short demo.
- A signup or waitlist button.
Do not write a novel. The page should match the promise you will use in outreach. If the page says "start in two minutes" and setup takes an hour of your help, change the page.
Logo and visuals
You do not need a brand agency. Recraft at recraft.ai is the one I would use for a simple logo, icons, and the images on the landing page. Ideogram at ideogram.ai is the backup when you need text inside an image to stay readable.
Pick one typeface, one accent color, and reuse them. That is enough for a first version.
App Store and Play Store screenshots
If you are shipping a mobile app, the store listing is the first product page most people see. Apple and Google want screenshots at specific sizes. Building those by hand in Figma is a waste of a week.
Use AppGrowthKit at appgrowthkit.com. Upload your raw app screens, drop them into device frames, add headlines, and export the sizes the App Store and Google Play ask for.
You still need real screens from the app. AppGrowthKit is for turning those screens into a listing, not for inventing a product you do not have.
Payments and analytics
Take money with Stripe at stripe.com. It is the default for a reason: checkout, subscriptions, customer portal, and failed-card emails are already there. Test a real card, a failed card, and a cancel before you invite anyone.
Watch what users do with PostHog at posthog.com. You want to know whether someone signed up, reached the main result, and came back. If you cannot see that, outbound will feel like guesswork.
You do not need a big dashboard. Three events are enough at the start: signed up, reached the core result, paid.
Support and docs
Put a chat widget on the app with Crisp at crisp.chat so the first users can reach you. For docs, use Mintlify at mintlify.com: a short getting-started page, how to connect the one integration you need, and how billing works.
Early support is just you answering quickly. The tool only has to make that easy.
Then start outbound
Once a new person can use the product, talk to a small group. One customer type, one promise, a batch small enough that you can read every reply.
If you need help finding that first group, read finding early adopters through outbound. If the product is still an MVP, pair it with using cold outreach to validate an MVP.
When you are ready to run the batch, use Omentir at omentir.com. It finds a focused LinkedIn audience, writes the first messages, and keeps replies in one place. Keep the volume low until the product and the message both survive a real customer.
Frequently Asked Questions
No. Use the ones that match what you are shipping. A web SaaS needs a working product, a way to take money, and a landing page. A mobile app also needs store screenshots. Code review is worth doing either way.
Use a reviewer that did not write the code. Critique at critique.sh is a local CLI that checks the change on your machine and returns evidence. Asking the same coding agent "does this look good?" is not a second opinion.
AppGrowthKit at appgrowthkit.com. Upload your raw app screens, add device frames and headlines, and export the sizes Apple and Google ask for. That is the listing people see before they install.
When a new person can sign up, reach the main result, and pay if you charge. You do not need a perfect product. You do need something a stranger can use without you sitting next to them.
Yes, if you are honest about what works. A small batch of design partners is fine. A large campaign that promises self-serve onboarding is not, until that path actually works.