SAMPLEDFree marketing tools, AI planning, and the honest route from prototype to a real app
Small businesses and creatives can plan, market and prototype for nothing. The hard part starts after the MVP: code signing, app review and offline architecture.
There has never been more free marketing infrastructure sitting unused. Small businesses and independent creatives can now research a market, write a plan, build a working prototype and put it in front of real customers without paying for a single seat of software. What that free tier will not do is carry you across the gap between a prototype and a product people can download, trust and pay for. That gap is where most projects die, and it is worth understanding before you start.
The free stack, in order of what to use first
Do not start with the tools. Start with the questions the tools answer.
- Demand — Google Trends (opens in a new tab) for direction, Google Keyword Planner (opens in a new tab) (free with an Ads account, no spend required) for volume, and Answer the Public (opens in a new tab) or Reddit search for the exact phrasing people use.
- Presence — a Google Business Profile (opens in a new tab) is still the highest-return free hour a local business can spend. Fill every field, add real photos, answer every review.
- Measurement — Google Analytics 4 (opens in a new tab) and Google Search Console (opens in a new tab) together, verified on day one. You cannot improve what you never measured from the beginning.
- Distribution — an email list on a free tier (Mailchimp, Buttondown, Beehiiv all start free), plus whichever two social platforms your customers actually use. Two done well beats six done badly.
- Creative — Canva (opens in a new tab) free, GIMP (opens in a new tab), DaVinci Resolve (opens in a new tab) for video, Audacity (opens in a new tab) for audio. Nothing here is a compromise at your stage.
- Learning — Google Digital Garage (opens in a new tab), HubSpot Academy (opens in a new tab) and Meta Blueprint (opens in a new tab) all issue free certificates that are worth exactly as much as what you do with them, which is more than nothing.
Using AI to write the plan, not to replace it
AI is very good at structure and very bad at knowing your customers. Use it accordingly.
A prompt that works better than "write me a marketing plan":
You are helping me plan a launch. My business is ___. My customers are ___ and they currently solve this problem by ___. My budget is $0 and my time is 6 hours a week. Ask me ten questions before you write anything.
The questions are the product. Answer them honestly, then have the model turn your answers into a one-page plan: one audience, one offer, one channel, one measurable target, twelve weeks. Everything else is a distraction you can add in quarter two.
Same principle for the product itself. Describe the single job your app does in one sentence. If you cannot, you do not have an MVP, you have a wish list.
Prototyping: three routes, honestly compared
| Route | Cost | Speed to something clickable | Who owns it after | Where it breaks |
|---|---|---|---|---|
| Build it yourself with an AI app builder (Lovable (opens in a new tab), similar tools) | Low | Days | You | Native features, app stores, scale |
| Prototype with ChatGPT/Claude and hand code to a freelancer | Low to medium | Days for mockups, weeks for the build | You, if you insisted on the repo | Handover quality, no one owns the architecture |
| Hire a local developer to build on top of one of the above | Medium | Weeks | You | Depends entirely on who you hired |
All three are legitimate for getting to a prototype. The honest read: build the first version yourself. Nobody else will iterate on your idea as cheaply or as ruthlessly as you will at 11pm on a Tuesday, and the version you hand to a developer after twenty of your own revisions is worth ten times the brief you would have written on day one.
The route that actually survives
Where the advice changes is the moment the thing stops being a demo. If the plan is a real product — installed, paid for, supported — hire or partner with a CTO or technical lead who has personally shipped past the MVP stage before. Not a developer who can build features. Someone who has been through the gates.
The gates are the part nobody warns you about:
- Code signing and certificates. Apple developer accounts, provisioning profiles, Android keystores. Lose a keystore and you cannot update your own app.
- App Store and Play review. Privacy nutrition labels, data-collection disclosures, account-deletion requirements, subscription rules, screenshots at every size. Rejections are routine and cost days each.
- Offline behaviour. A web MVP assumes a network. A real app cannot. Local storage, sync conflicts, queued writes, migrations on device — this is a genuine re-architecture, not a port.
- Push, permissions and background work. All platform-specific, all reviewed.
- Updates and rollback. Once users have installed a version, you own every version that is still out there.
- Support and telemetry. Crash reporting, versioned APIs, a way to tell whether the problem is one user or all of them.
A technical lead who has crossed those before will make design decisions in month one that save the rewrite in month nine. Someone who has only built prototypes will, in good faith, build you a prototype.
A worked example: Sampledex Release OS
Sampledex Release OS started exactly this way. The first version was a website built on Lovable — fast to stand up, fast to change, good enough to test whether producers actually wanted a release planner or just said they did. That question got answered cheaply, which is the entire point of the free-tools phase.
Moving it to a real app was a different project. The data model had to work offline, because the moment a producer is in a studio with no signal is exactly the moment they need their release checklist. Sign-in, storage, sync and the release timeline all had to be rebuilt around that assumption rather than bolted on. Then came the account, the certificates, the review submissions, the privacy disclosures, and the slow business of shipping updates to people who already had the old version installed.
None of that invalidates the Lovable start — the start is what made the rest worth doing. But the second phase needed someone who had already made those mistakes on someone else's product.
If you ever plan to scale, hire the developer
Building it yourself on Lovable is a legitimate way to start, and for a lot of businesses the thing you build that way is the whole product. But almost everyone eventually says the words "what if this grows" — and the version of the app that grows is rarely the version you prototyped.
So the honest rule is this: code it yourself to prove the idea, and hire a developer the moment scale is the plan rather than the daydream. Not any developer — one who has actually taken a web product through to a shipped application, because that path has gates that catch first-timers: code signing certificates, notarisation, App Store and Play review, crash reporting, versioned updates for people already running an old build, and rebuilding features to work offline instead of assuming a connection.
The other reason to hire that person early is that they can give you something you can hold before you commit to a store at all. A competent developer should be able to wrap your product as a desktop build — Tauri or Electron — so you and your team can install it and use it locally on Windows, Mac and Linux, or write a native Swift app if you only care about Mac and iPhone. Those builds are cheap next to a full store launch, and they surface the offline and performance problems while they are still cheap to fix.
Ask any candidate one question: show me an app you took from browser to store, and tell me what broke. The answer tells you everything.
What to do this week
- Verify Google Business Profile, Analytics and Search Console. One evening.
- Run the ten-question prompt above and write the one-page, twelve-week plan.
- Build the ugliest possible clickable version of your idea and show it to five real customers.
- Only after those five conversations, decide whether you need an app at all. Most of the time the honest answer is a better website and an email list — and that answer costs nothing to act on.
If the answer really is an app, budget for the person who has shipped one, not just the person who can build one.