Blog › Build Story · Product Scope
It would have been easy
to build ten features. I built one job.
Every solo founder feels the pull to widen scope the moment the first version works. Here's why I resisted it, what got cut, and what a narrow product actually buys you.
1
job the product exists to do
550
templates rebranded in one focused batch
11 min
because scope stayed narrow enough to get this fast
0
unrelated jobs bolted on to look bigger
The temptation to build everything
The moment a first version works, the feature ideas start arriving faster than you can write them down. Template creation. Ongoing brand management. A dashboard for tracking brand consistency over time. General document editing while you're in there anyway. Every one of those sounds reasonable in isolation, and every one of them was a genuine temptation once BrandSwitch proved it could rebrand a real document library properly.
The pull isn't really about ambition. It's about the fear that one narrow job won't be enough to matter, so the instinct is to widen the net before you've even finished proving the first job works. I felt that pull constantly, and it's worth naming honestly rather than pretending scope discipline came easily.
How I chose the single job
I went back to the actual problem that started this: a real document library, in the wrong brand, that needed fixing without weeks of manual admin work. Not "brand management" as a category. Not "document tooling" as a platform. One specific, bounded job: take documents that already exist and get them into the right brand, properly, across every part of the file. Everything the product does has to trace back to that job directly, or it doesn't belong.
What got cut and why
Template creation
A different job entirely - helping teams create new documents, not fix existing ones. Left to the tools already built for it.
Ongoing brand management
Turns a focused tool into a platform with upkeep obligations that dilute the one job it's actually good at.
General document editing
Would have made the product more powerful and much less trustworthy for the specific job people actually came for.
A micro-SaaS earns trust by doing one job completely, not ten jobs partially.
How a narrow scope shaped quality
Staying narrow is what made it possible to go deep on the parts of the job that actually matter - walking every XML part of a document, handling headers, footers and tables consistently, testing against genuinely messy real-world files instead of tidy demos. That depth doesn't happen if the same amount of time and attention is spread across ten loosely related features instead. Scope discipline wasn't a constraint on quality. It was the precondition for it.
It also made the product easier to trust. Someone evaluating a tool that claims to do one thing can actually check whether it does that one thing well. A tool that claims to do everything is much harder to evaluate, and much easier to be disappointed by once you find the corner it didn't really finish.
What earns its way onto the roadmap
One test, applied consistently: does this make the single job more complete, or does it give the product a second job. Support for another file format that documents actually arrive in passes that test - it's still the same job, done more thoroughly. A feature that turns the product into a brand management platform doesn't, no matter how often it gets requested. The roadmap isn't short because there's nothing left to build. It's short on purpose, so the one job stays the one thing the product is actually trusted to do.
Quick answers
Why does BrandSwitch only do document rebranding?
Because a micro-SaaS earns trust by doing one job completely, not ten jobs partially. Every feature considered for the product gets tested against whether it strengthens that one job or just adds surface area to maintain.
Doesn't a narrow product limit growth?
It limits a certain kind of growth in the short term, and that's a deliberate trade. A tool that does one job properly earns the trust to expand later. A tool that does many jobs badly rarely gets the chance.
What kinds of features get cut from the roadmap?
Anything that turns the product into a different kind of tool - template creation, ongoing brand management, general document editing - even when it would be technically straightforward to add. If it's not the job the product exists to do, it's out.
What does it take for a new feature to earn its way onto the roadmap?
It has to make the single job more complete, not just more expansive. A feature that helps rebrand documents more thoroughly earns its place. A feature that gives the product a second unrelated job doesn't, no matter how useful it might sound in isolation.
The one job, in production
BrandSwitch still does exactly one thing: rebrand documents you already have. Upload, set your brand once, download the result. Nothing wider, and that's deliberate.
See the one job, done properly
Document rebranding, and nothing else, on purpose.