I'm a marketer with a computer science degree, not a full-time developer. I can read code. I don't enjoy writing it eight hours a day.
In 2025 I built Sendrise anyway. It's a cold email platform: you find leads, verify their emails, write personalized emails with AI and run campaigns from one dashboard. It started as a rough MVP and grew into a product with lead management, campaigns, a CRM and analytics. I launched it on Product Hunt in early 2026.
I built it with Lovable for the product and interface, Supabase for the database and login, and AI models for the writing. No engineering team. This is what I'd tell any marketer who wants to do the same.
The stack
| Layer | Tool | Why I picked it |
|---|---|---|
| Product and UI | Lovable | I describe screens and flows in plain English and get real React code that I own |
| Database and auth | Supabase | Postgres, row-level security, login and file storage in one place |
| AI | LLM APIs | Writing emails, personalizing them and enriching leads |
| Pricing | Credits | Costs scale with usage, which matches how people actually use outreach tools |
Nothing exotic, and that's on purpose. Boring tools have answers on Google when something breaks at 1 a.m.
Write the spec before the first prompt
AI builders are fast. That's the danger. You can build the wrong thing in an afternoon and spend a week undoing it.
Before I opened Lovable, I wrote down every screen, every table, every user role and what each role can see. It took two days and saved me weeks. For Sendrise the core objects were workspaces, leads, campaigns, sequences, steps, inboxes, messages and events.
If you can't describe your product on one page of plain text, you're not ready to prompt it.
Model the data first, then the screens
Getting the tables and the security rules right early matters more than anything else. Change your data model in month three and it touches every screen, every query and every permission.
My rule: every table gets row-level security on day one, even if the policy is just "the owner can read and write their own rows". Retrofitting security later is how data leaks happen.
Build one complete flow before anything else
For Sendrise, that flow was: import leads, verify the emails, write a sequence, launch the campaign, see the replies. I didn't touch analytics or settings until that flow worked end to end with real data.
One working flow beats ten half-built screens. It also shows you very quickly which parts of your spec were wrong.
Then add depth, one feature at a time
Once the core flow worked, I added the CRM view, analytics, templates and AI writing. Each one was a focused prompt with clear acceptance criteria, tested before I moved on.
How I prompt
These rules came from breaking things:
- One feature per prompt. Big prompts produce big, fragile changes, and when something breaks you can't tell which part caused it.
- Write the acceptance criteria. "A user can import a CSV of 5,000 leads, map the columns and see duplicates flagged" gets a far better result than "add CSV import".
- Ask for a plan first on anything risky: data model changes, login, billing. Read the plan before you let it write code.
- Read the diff. You don't have to write code to understand what changed, and you'll catch half your bugs this way.
- Keep a project knowledge file with design rules, naming conventions and business logic, so every prompt starts from the same context.
Ship the marketing with the product
This is where most builders go wrong. They spend three months on the product and three days on distribution.
I built the landing pages, onboarding emails, pricing page and launch plan alongside the product, not after it. Distribution is the part I'm actually good at, and it would have been silly to leave it until last. If you're a marketer learning to build, that's your unfair advantage. Use it.
What I'd do differently
- Credit-based pricing needs guardrails from day one: usage limits, a visible balance and a warning before someone runs out. I added these late, and early users noticed.
- Deliverability is a product feature, not a setting. Warm-up, sending limits and authentication checks belong in the main flow, because users won't go looking for them in settings. My cold email playbook explains why they matter so much.
- Security reviews aren't optional. Check the row-level security on every table before you invite real users, and again after any big change.
- Your first users are your testers. Ship to a small group, watch them use it, and fix whatever confuses them before you launch publicly.
Should you build your own tools?
If you're paying for five tools that each do 20% of what you need, probably yes. Start with one painful workflow. Build the smallest version that removes the pain. Use it yourself every day for a month. That's how Sendrise started, and it's how I'm building SendReach for LinkedIn outreach now.
If you'd rather someone else built it, that's fine too. Not every marketer needs to become a builder. But every marketer should know what's possible now, because their competitors will.
