When Is a Tool a Feature, and When Is It a Separate Product?

A working tool creates an attractive question: should this become its own product?

A new logo, a domain and a landing page can make separation feel like strategy. It is not. A technical surface becomes a product boundary only when it carries an independent user job, value loop and ownership model.

A separate URL is not a separate product

I do not classify a surface by its URL. I ask:

• Does the user arrive for a distinct job?
• Does the tool create meaningful value on its own?
• Does it have its own input → output loop?
• Can it be understood without using the parent product first?
• Does it need its own state or history?
• Is independent discovery useful?
• Does its value justify separate release and maintenance ownership?

If most answers are no, it is probably a capability inside an existing system.

What should remain a feature

A function that completes the parent product’s job often belongs inside that product.

A small formatter used inside an existing audit flow may not need another brand, landing page, analytics surface and deployment. The moment you separate it, you create new obligations: navigation, copy, SEO, release, documentation, maintenance and user expectations.

A subdomain is not free organizational space.

What deserves independence

Some tools lose value when they are buried inside a larger website. If a user can arrive with a specific problem, provide an input, receive a useful output, keep or share that output and return for the same job later, the surface starts to justify its own product boundary.

At that point, the URL follows the product decision.

The rule for the ahmetcanal.com ecosystem

The main site remains the authority and decision surface. Projects prove working systems. Services describe intervention routes. Toolkit surfaces technical audit capabilities. Capabilities describe the system layers I work on.

Independent tools can live on their own subdomains when they produce independent value. But “I built something new” is not enough.

Every new surface increases the total context and operating cost of the ecosystem.

A boundary test

I use six practical checks:

Job: can the user describe the tool’s independent job in one sentence? Entry: can they arrive directly without first understanding the parent product? Output: does it create a useful result on its own? Return: is there a reason to come back to this surface? Ownership: does it have separate state, data or release concerns? Cost: is the value larger than the additional maintenance surface?

If only the “cool URL” test passes, I keep it inside the existing system.

For a solo operator, this is also a focus decision. Every product boundary creates a roadmap, bugs, analytics, copy and support context. Good architecture protects operator attention as well as user experience.