What 10+ shipped micro-apps taught me about building with AI
AI makes shipping fast. Distribution stays hard. After 10+ micro-SaaS apps, here is what I learned about product decisions and the limits that actually matter.
GTM Architect & Growth Operator · Now · 2 April 2026
TL;DR · Key insights
- Micro-apps solve one problem correctly: that's both their strength and their design constraint
- AI assistance has made solo shipping of useful, real tools feasible for non-full-stack builders
- The failure mode is scope creep that turns a micro-app into a half-baked SaaS
- Distribution remains the hardest problem: AI doesn't solve reaching the right people
The apps at app.wojciech.io were mostly built in 2024-2026 (see the full list at /work/). A mix of productivity utilities, niche market tools, and internal operator tools that eventually became public. Some are actively used. Some are experiments I learned from. A few are both.
Here’s what I’ve learned about building this kind of portfolio with AI assistance.
The micro-app definition
A micro-app solves exactly one problem for a specific person in a specific situation. Not a category of problems. Not a platform. One problem.
- Działka+: finds building permit status for Polish land parcels (one query, one answer)
- Paczka+: tracks Polish courier deliveries with better notifications than the native apps
- Resume+: formats a CV into a clean, ATS-compatible PDF in under 60 seconds
- NotchCue: keeps speaker notes near the camera during video calls
Each of these has a description that fits in one sentence because the problem fits in one sentence. When the problem description starts requiring “and also”: that’s the moment scope has crept past micro-app territory.
How AI changed the build process
Before AI assistance, shipping a real, deployed tool as a solo operator required either a frontend background or significant help. Shipping a native macOS app as a non-Swift developer was essentially off the table.
AI changed this in specific ways:
The scope creep pattern
Every micro-app I’ve built has had a moment where the temptation to add “just one more thing” appeared. Paczka+ tracking → add a package history view → add a price comparison tool → add crowdsourced delivery speed data.
Each addition is individually reasonable. Together they turn a tool that solved one problem correctly into a tool that solves three problems adequately.
What I’d do differently
Launch earlier
Charge earlier
Pick distribution before picking the problem
The portfolio value
The apps collectively serve as proof that I can ship real products, not just design systems or advise on GTM strategy. That’s worth something independent of any individual app’s revenue. For the kinds of engagements I take on: embedded growth operator, AI systems builder: the ability to produce working software is a differentiator.
The portfolio is also a learning substrate. Each app taught me something about user behavior, deployment, pricing, or technology that I’ve applied in subsequent work. The ROI on the time is higher than any single app’s direct output would suggest.
Related: macOS Teleprompter for MacBook Notch: building a native Swift app · Astro and Cloudflare Pages Portfolio Build with AI Workflow: how I rebuilt my site
