Most engineering orgs have systems you can't touch—legacy tools, rigid workflows, inflexible platforms. You know they're inefficient. But you're not going to get buy-in for a full rewrite, and you're not authorized to change the requirements.
So what do you do? You optimize the fragment.
That’s where micro-apps come in—not as platforms, not as products, but as scalpels for automating repetitive, constrained workflows when everything else is locked down.
A Common Case: “Send This Report Every Week”
You’re told to send a status email every Friday at 4PM. It needs three metrics pulled from a dashboard, one from a database, and a copy-pasted summary from last week.
You can’t change the requirement. You can’t change the dashboard. You can’t change the process.
But you can write a 50-line script that grabs the metrics, formats the body, and fires off the email.
You’ve just reclaimed 30 minutes per week—and eliminated the human error from a repetitive task.
That’s the point of micro-apps. They optimize the edge cases when the system is unfixable.
Workflow Fragmentation Is the Norm
You don’t work in a clean pipeline. You work in a mess:
- Jira tickets that trigger manual emails
- Dashboards you export just to reformat in Excel
- CI failures that need copy-pasted logs to Slack
- Environments with no API, just a browser UI and guesswork
You can’t refactor these systems. But you can wrap the friction points with micro-apps.
Not big systems. Not platforms. Not products.
Just sharp tools for well-scoped problems.
Micro-App Philosophy
If you’re building micro-apps, follow these principles:
- Single responsibility: One input, one output, one job.
- Zero config: If it needs onboarding, it's too big.
- Fast to use: Ideally <1s interaction time.
- Local-first: Run it from your machine, or a single server. No infra complexity unless necessary.
- Throwaway-friendly: Build fast. Be ready to delete fast.
A good micro-app saves time on day one. A great one can be rebuilt in an afternoon if it disappears.
Don't Abuse Them
Micro-apps are not a substitute for strategic platform work. If you:
- Have 7 tools doing the same thing
- Built a micro-app that every team now depends on
- Keep extending the same script until it’s a full stack app
…you've gone too far.
Use micro-apps to patch workflows, not design them. They’re drop-in fixes, not foundations.
They should automate what exists, not entrench what's broken.
A Healthy Micro-App Culture
Want your org to benefit from this pattern? Set some cultural defaults:
- Let engineers ship small tools with minimal process.
- Provide one-click hosting (e.g. GitHub Pages, Netlify, internal runners).
- Maintain a simple internal app catalog with short-lived entries.
- Celebrate small wins: highlight tools that eliminate 5–10 minutes of weekly toil.
This isn’t about building internal platforms. It’s about removing local friction without red tape.
Closing Thoughts
Micro-apps are for the 20% of workflows where the system won’t change, but your time is still being wasted.
They are surgical, ephemeral, and high-leverage—not scalable solutions, but highly effective responses to immovable constraints.
So next time you’re forced to do something dumb, manually, again:
Don’t file a ticket.
Don’t ask permission.
Build a tool. Use it. Delete it later.
Small tools. Big leverage. No excuses.
Original Article: https://t128n.github.io/writings/2025-04-17_micro_apps
Top comments (0)