When Sebastian Pedavoli talks about shipping, he doesn’t sound like a hype video. He sounds like someone who knows where the time goes, and how to stop wasting it.
Seb is CPO at Sked Social by day and an indie founder by night. After years of managing teams (and writing less code), he wanted a faster way to turn ideas into working software. MakerKit became the spine. AI the power assist. Reddit the truth serum.
“MakerKit let me drop my IP into a real product skeleton and get to market fast. The time-to-market difference was… profound.”
He’s behind Watch This Page, a site-change monitor, and Componentry, a cycling app he’s migrating to MakerKit. One came from market conversations. The other from a personal itch. Same lesson: ship the smallest thing that proves the problem, then listen hard.
The research loop that actually happens
No ads. No launch checklist. Seb started with a tiny proof-of-concept to answer a single question: is this even possible? Once he had a “yes” he went where the conversations already were - Reddit.
Not to pitch. To ask.
“Does anyone have this problem?” “How would you solve X?” “What cadence would you want updates?”
That last question flipped his roadmap. He arrived assuming daily/weekly digests. The threads made it obvious: monthly and quarterly matter more. It’s a small change with a big outcome: you align the product to how people actually work, not how you wish they worked.
Reddit isn’t always friendly to makers. Fine. If you can’t sell there, you can still learn there, faster than anywhere else. Show up with questions, not links. Use the language you see in threads in your UI copy and onboarding. And when someone gives you an unexpected answer, take it seriously. That’s the whole point of being there.
What this looks like in practice
- Phase 0 — Feasibility: one script, one narrow outcome, confirm it’s possible.
- Phase 1 — Discovery in the open: 5–10 questions across a few subreddits; save verbatim phrases.
- Phase 2 — Thin slice build: ship only the feature that answers the loudest pain.
- Phase 3 — Cadence fit: tune delivery to how users actually consume (daily vs weekly vs monthly/quarterly).
- Phase 4 — Small cohort: free access for a handful of people who gave good feedback; turn them into champions.
None of this requires a launch. It just requires being willing to show work-in-progress and ask better questions.
MakerKit + AI, minus the fairy dust
AI helped Seb get back up to speed after a long gap writing code. It unblocked errors, explained unfamiliar pieces (hi, Expo), and refactored when something got messy. Useful. But not magic.
“There’s always core logic AI can’t quite do, especially when you’re inventing something. MakerKit + a bit of AI gets you a long way.”
MakerKit covers the boring-but-critical surface area such as auth, sessions, data layer, forms, billing, dashboards, so the “idea code” stays small.
AI then accelerates your learning and glue-work. That combination gets you to “a real app that real people can touch” quickly, without pretending a one-click SaaS generator is going to nail your edge cases.
The security reality
AI will confidently ship vulnerabilities. If you’re storing user data, you can’t vibe-code and hope for the best. Start privacy-first and security-first. It’s easier than retrofitting later, and in many markets (EU especially) it’s not optional. The short version: let AI suggest, but you decide. Guardrails over vibes.
An “oh no” worth mentioning
Locally, Seb’s headless-browser pipeline purred. In production, it hit memory ceilings and fell over. That’s the stomach-drop moment: is the premise even viable?
He picked his battle. Stripped the browser footprint. Tuned the pipeline. Kept it in-house. If it hadn’t been solvable, he would’ve called an API and moved on. The goal isn’t purity, it’s momentum. You keep moving toward value, whether you win by engineering or by credit card.
Rule of thumb: hand-roll the parts that are your product; buy the rest.
Finding the line between “enough” and “not yet”
Shipping is a bet. Every feature is a chip. Seb reduces risk with boring, reliable habits:
- Put rough ideas in front of 10 people early (Figma is enough).
- Stack-rank the problems you might solve.
- Ship only the top one or two.
- Invite a small beta and let them argue with your assumptions.
You don’t need clicks to learn. A 20-minute screenshare of a half-finished build usually beats two silent weeks. The goal of v0 isn’t “complete.” It’s “clear enough that the next conversation is better.”
A simple way to choose what ships
Ask: If I ship X, what new thing will I learn next week that I can’t learn today? If the answer is “not much,” X probably isn’t the thing to ship.
If you’re “non-technical” (and even if you aren’t)
Try building it yourself first. You’ll learn the stack, sharpen the vision, and if you hire later, you’ll brief better and spend less. Use AI like a mentor, not an autopilot. Don’t outsource the thinking that makes your product yours.
And if you do hire? You’ll recognize “good” because you’ve pushed the boulder yourself. You’ll also be able to push back on waste - because you’ve seen what “thin” looks like.
Minimum skill to aim for: read and edit code you didn’t write; wire a simple feature end-to-end; deploy without panic. That alone changes how you run the project.
Channels are shifting (again)
Seb’s already seeing traffic from LLMs (ChatGPT, Gemini) alongside search. SEO isn’t dead, but the job is different. Structure content so models can ingest it and surface you in answers. Publish small tools and data that are easy to parse. Well-labeled pages beat generic blogspam.
Practical moves:
- Keep shipping useful pages with clear headings, schema/structured data where it helps, and examples that answer real questions.
- Build “mini tools” tied to your product that produce a result people can use.
- Use the exact language your users use (the stuff you copied from Reddit). Models notice.
What I’d steal from Seb’s playbook
- Validate in public spaces where people talk plainly.
- Let cadence (daily/weekly/monthly/quarterly) come from users, not your roadmap.
- Treat features as bets; stop when the bet isn’t paying and place a smarter one.
- Keep the core logic in-house; rent commodities without guilt.
- Don’t wait for “ready.” Ship the slice that improves the next conversation.
MakerKit exists for this loop
MakerKit’s job is to remove the scaffolding tax so you can spend energy on the problem, the cadence, and the conversations. If your world is Supabase and you need non-developers in the data safely, keep an eye on Supamode, our self-hosted super admin that lets teams work in the database without handing them the database.
Three takeaways to ship on
- Prove the problem, not the platform. A script + 10 honest conversations beats a “perfect” v1.
- Ship the smallest thing that moves the next conversation. Then ask better questions.
- Pick your battles. Hand-roll the parts that are your product. Buy the rest.
Links
Here are some links to the products and services mentioned in the post: