Why Specify exists

Make the website aware of more of the business behind it.

Catalogues are built from products, options, descriptions, filters and images that have already been published. Customers keep asking for different dimensions, materials, combinations, deadlines, applications and modifications, and the catalogue has no way to represent any of it.

Where the catalogue problem is concrete enough to govern.

The pattern Specify is built for shows up wherever these conditions hold together:

  • The product is configurable but not infinitely flexible.
  • Drawings, dimensions, materials, installation and phasing matter.
  • Commercial viability depends on capability and explicit constraints.
  • Several teams may need to approve the outcome.
  • The catalogue regularly represents less than the business can actually deliver.
  • A plausible answer can create real operational risk when it is mistaken for an approved offer.

That describes configurable products, custom interiors, personalised goods, made-to-order manufacturing and specification-led B2B supply. It is a commercial shape, not an industry.

Specify proves its core objects, Structured Opportunities, Capability Maps, Constraint Records, Decision Records and the Opportunity Ledger, against that shape rather than against one market.

Read the vision

The Capability Gap

A Catalogue Blind Spot is an area of customer demand that the business may be capable of serving but that its published catalogue cannot see, interpret or respond to.

The business itself may possess:

  • Additional materials
  • Machinery and production methods
  • Supplier relationships
  • Configurable combinations
  • Modification capability
  • Expert knowledge
  • Approval processes
  • Commercial flexibility

When this operational knowledge remains offline, the website may return no result even though a viable product, modification or alternative exists. The Capability Gap is the difference between what the business can actually deliver and what its website enables customers to discover, configure or request.

The larger the Capability Gap, the more likely the business is to:

  • Lose viable demand
  • Create unnecessary sales work
  • Issue Premature No responses
  • Miss responsible alternatives
  • Appear less capable than it really is
  • Forget what the market repeatedly requested

Specify was created to turn dispersed capability into a shared commercial model and turn unmet demand into an informed decision.

What Specify believes

Five clauses, not slogans.

  1. A Catalogue Blind Spot is not a business decision

    The limit of the published catalogue should not automatically be treated as the limit of the business.

  2. A customer request should become a Structured Opportunity

    Informal language must be translated into facts, unknowns, alternatives and required next actions before it can be evaluated responsibly.

  3. Capability and constraints must be explicit

    Recommendations should be grounded in a Capability Map and approved Constraint Record, not plausible-sounding assumptions.

  4. Decisions must remain attributable

    Every approved, modified, referred or rejected outcome should be preserved in a Decision Record with its reasoning and owner.

  5. Unsuccessful demand should become commercial memory

    The Opportunity Ledger should record what customers wanted, including when no sale was possible.

Founding stage

Built by engineers who have worked inside the systems Specify is changing.

Specify was founded by Theodor Guttesen and Michael Khazzoum, two software engineers who met while working as consultants at Netcompany.

Between them, they have built and operated B2B ecommerce platforms and large public-sector systems, working across software development, requirements clarification, customer collaboration, releases and ongoing operations.

The idea for Specify grew from direct experience with the limits of catalogue-based ecommerce. While working on Brødrene A&O Johansen's B2B platform, Theodor saw how requests for custom products could still end in an email or phone call because the webshop could not express everything the business was capable of producing.

Both founders left their consulting roles to build Specify full time. The product's architecture, backend, frontend, infrastructure and AI workflows are developed by the founding team.

  • Two technical co-founders
  • Experience building B2B ecommerce and enterprise software
  • All core product development completed by the founders
  • Both founders working full time on Specify
Pencil-drawn portrait of Theodor Guttesen

Co-founder & CEO

Theodor Guttesen

Software engineer and former Netcompany consultant with experience in B2B ecommerce, public-sector digitalisation and customer-facing software delivery.

At Brødrene A&O Johansen, Theodor worked on its B2B ecommerce platform across development, checkout improvements, requirements clarification and ongoing delivery. He later contributed to systems for Landsbyggefonden, KOMBIT and Udbetaling Danmark.

His experience seeing custom-product requests fall outside the standard ecommerce flow helped shape the original problem behind Specify.

Theodor Guttesen on LinkedIn
Pencil-drawn portrait of Michael Khazzoum

Co-founder & CTO

Michael Khazzoum

Systems scientist and former Netcompany consultant with experience building large-scale enterprise software across backend, frontend and technical delivery.

Michael worked on a public-sector platform for Landsbyggefonden using .NET, C# and Blazor, supporting workflows covering inspections, maintenance and case management.

At Specify, he works across the product architecture, platform infrastructure and AI systems.

Michael Khazzoum on LinkedIn
Product
Built by the founding team
Experience
Production software and B2B ecommerce
Commitment
Both founders working full time
Current evidence
Working system available to inspect

For investors

Specify is raising a pre-seed round

The business model, the market, what makes this defensible and what the round is for.

Read the investor page

Run one enquiry through it.

The fastest way to judge whether this is real is to put a request your catalogue could not answer through the audit and read what comes back.

Audit one enquiry