Home • About • Projects • Blog • Resources • Contact
Update: TinyLaunch is now Launchling! Same idea, new name and better experience.
A few days ago, I started my MVP for TinyLaunch — a tool to help non-technical solo founders get from idea to action (see my previous blog post for more details). I started with Framer to move fast, but quickly hit its limits. Here's how I rebuilt the app in React (for the first time in nearly 6 years!) and what I learned about no-code, debugging, and building things that last.
When Framer Was Enough — and When It Wasn’t
Framer was incredible for quickly putting something tangible that could be shown to users. The onboarding flow, the lightweight GPT-powered plan generation, and even initial Airtable integration all came together surprisingly fast. However I held off showing it to anyone just yet as I felt there were several things that needed to be improved before I had anyone test out the idea.
As the feature complexity increased (albeit not massively), Framer’s limitations started to bite:
- Handling rich text formatting and complex markdown rendering was a pain. I wasted a lot of time on this, but I really didn’t want it to look unprofessional.
- API integrations became fragile and complicated, especially when I wanted to implement feedback submission.
- Styling and layout flexibility felt constrained, making the UI harder to polish.
- But more critically, I quickly maxed out Framer’s free and even the lower paid tiers — and the pricing for scale started to feel prohibitive.
I started patching around the issues, but it quickly became clear I needed more control. I also realised I faced a choice: pay more to continue in Framer or invest in building the app myself.
Choosing to Build My Own React App
I decided to take the plunge into building TinyLaunch as a React app powered by Vite. This meant:
- More control over the user experience and UI design
- Ability to fully customise the backend integration with Airtable and Zapier
- Full ownership of the API routes, making debugging and expansion smoother
- Avoiding the escalating costs and limits of a no-code platform
- Having foundations that could be built out if this idea proved to have legs
It took a bit of time to start up the React project, configure environment variables, and rewrite routing logic (I wanted to support clean URLs and parameterised plan views). I’m also aware this wouldn’t be super straightforward for someone with no engineering background at all, but I did find that ChatGPT was pretty good at guiding me through the bits I got stuck on (a bit like pairing with a slightly forgetful Senior engineer really). One thing I did find made a big difference - when the debugging steps would go full circle, it made better sense to start a new chat, provide sufficient context and a strong prompt, but have the debugging started from fresh (avoiding the confusion of memory issues and hallucination in long chats).
Debugging Vercel API & Airtable Integration
The biggest headaches came from:
- Deploying and debugging Vercel serverless functions for the API routes
- Managing CORS issues and getting the Airtable fetch logic right
- Aligning Zapier’s Code step and webhooks to create consistent Plan URLs
- Handling route rewrites and preventing conflicts between frontend routing and API calls
One of the trickiest bugs I hit was a 500 error on the deployed plan pages — Vercel would show a cryptic FUNCTION_INVOCATION_FAILED, but no logs from the API handler were printing. After digging into the logs, configs, and build process, I finally traced the issue to a silent failure: my serverless function was importing node-fetch@3, which is ESM-only, using CommonJS syntax (require). That caused the function to crash at load time, before hitting any code.
The fix? Downgrade to node-fetch@2, which works with CommonJS and is compatible with Vercel’s serverless runtime. Once that was sorted, I also refactored the route logic, ensured my vercel.json had clean rewrites for SPA routing, and added defensive error handling both server- and client-side.
Oh the nostalgia of one seemingly small dependency mismatch breaking your whole app - it reminded me just how little time I ended up coding as opposed to debugging when I was an engineer.
What I Learned
- No-code and low-code tools are fantastic for rapid prototyping, but not always for sustainable scale or complex logic (although perhaps Framer just wasn’t the right choice for me - perhaps if I’d been clearer on MVP before starting, rather than iterating as I went, I would have chosen a more appropriate tool)
- Ownership of the entire stack (frontend, backend, API routes) pays off in flexibility and debugging ease
- Environment variable management and deployment config require special care, especially on serverless platforms like Vercel
- Zapier integration can be a powerful bridge but adds complexity that needs rigorous testing and version control
- Clean URL design and routing conventions need to be baked in from the start to avoid headaches later
- Tools like ChatGPT can help with debugging - but you have to be smart about it, it sometimes pays to have a clean chat where you can set up the context without any noise.
What’s Next for TinyLaunch
Now that I’ve rebuilt the core experience in React and deployed a reliable backend, I’m focused on:
- Polishing the UI and UX with better styling and responsive layouts
- Expanding onboarding flows and GPT-driven guidance
- Improving feedback loops to continuously improve the AI prompts and plan relevance
- Exploring integrations beyond Airtable and Zapier for better data automation
- Planning outreach and early user testing to validate new features
It’s been a bit frustrating, but a lot of fun and it’s lovely to be building something again. I think it’s also underscored the importance of balancing rapid prototyping with sustainable architecture — and knowing when it’s time to rebuild.
Try it now
Turn your idea into a tiny, tangible prototype — with a little help from Launchling.
👉 Try Launchling – no signup, no jargon, just a gentle push forward.
If you're working on a similar solo builder project — or curious about combining AI, product thinking and lightweight stack choices — I’d love to hear from you.