Image optimisation sounds like a small product until you start listing everything it could become.
More formats. More controls. More presets. Accounts. Permanent history. Cloud storage. Queues. Team workspaces. APIs. Bulk processing. Advanced codecs. Asset management. Editing.
The list grows faster than the value proposition.
As I develop Pithform, I am deliberately resisting that expansion.
The product starts with a narrower question:
Can I make the common job of reducing image weight feel fast, clear and trustworthy?
That is enough to build a product around.
Three formats are a decision
The launch surface focuses on:
JPEG / PNG / WebP
That is not a claim that other formats do not matter.
It is a boundary.
Every additional format introduces another set of encoding behavior, edge cases, expectations, testing requirements and support questions. Supporting something publicly means more than getting it to work once on a developer machine.
It means being willing to treat it as part of the product.
A narrow launch surface makes that commitment manageable.
It also gives the product a clearer identity. Pithform does not need to become a universal media-processing suite before it can be useful.
Session-only on purpose
Another deliberate constraint is persistence.
Pithform is designed around session-only processing rather than becoming a permanent image library.
That removes an entire category of product complexity:
storage management, retrieval, user libraries, retention policy, cross-session state, privacy expectations and account history.
More importantly, permanent storage is not essential to the core job.
The user brings an image, optimises it, takes the result and leaves.
That workflow is complete.
Adding persistence simply because software products are expected to “remember everything” would change the nature of the service.
Ephemeral can be a feature.
Meter the result, not the attempt
The planned commercial model follows the same logic.
Usage is designed to be based on successful optimisations rather than every interaction with the system.
That makes the unit easier to explain:
if Pithform successfully produces the useful result, it counts.
This is not a revolutionary billing mechanism. It is simply aligned with what the user came to accomplish.
The product should avoid making people think about infrastructure units when they are trying to make an image smaller.
Keep the laboratory out of production
There is another boundary that matters just as much as the public feature list.
Experimental processing should not quietly become production infrastructure.
Pithform can have internal tools, qualification work, local experiments and specialist processing that help develop the product. Those things do not automatically belong in the customer environment.
The production surface should contain production-authorised behavior.
That separation makes the public product easier to reason about and protects experimental work from becoming an accidental dependency.
It also creates a healthier development loop: the laboratory can be messy because the product does not have to be.
Narrow products are easier to understand
Feature breadth is often treated as maturity.
Sometimes it is.
Sometimes it is just accumulation.
A product can become harder to explain as it becomes more capable. Every new option introduces another branch in the user’s mental model.
Pithform benefits from being understandable in a sentence.
Bring an image.
Remove unnecessary weight.
Preserve the form.
Take the result.
That clarity is worth protecting.
Constraint creates a stronger roadmap
“Deliberately narrow” does not mean “never expand.”
It means expansion has to earn its way into the product.
A new format should enter because it solves a meaningful customer problem, not because a library supports it.
Persistence should appear only if there is a real workflow that requires returning to previous jobs.
An API should exist when there is a product case for programmatic processing, not because APIs make software feel more serious.
The roadmap becomes a sequence of justified additions rather than a collection of possibilities.
That is the underlying product position.
Pithform does not need to do everything an image tool could do.
It needs to do a specific job well enough that the boundaries feel intentional.
