1. Thesis

1G (one-gram tech) is a methodology for building new software products where product–market fit is unknown.

“1G (‘one-gram’) and 10G (‘ten-gram’) are units of product scope:
1G = the smallest complete user-facing feature that could stand alone.
10G = the full “platform” vision built from many such units.”

The core claim:

Ambitious “10G” products should be built as a stack of 1G units – tiny user-facing features that could stand alone.
If it cannot stand alone, it is support work or waste.
10G is the narrative; 1G is the build unit that prevents all-or-nothing releases.

2. Assumptions

This methodology assumes:

Engineering time is scarce capital, regardless of cash on hand.
User value is uncertain for genuinely new ideas – many guesses miss.
Being wrong is expensive, and extra scope multiplies the cost.

If these premises are rejected, the methodology does not apply.

3. The 1G Gate (non-negotiable rule)

Before any user-facing feature receives engineering effort, it must pass the 1G gate.

If this were shipped on its own, as a tiny standalone product for a specific segment,
would it have a plausible path to adoption and revenue on its own?

A candidate feature counts as a 1G only if all of the following are true:

Specific user / segment

There is a clearly defined type of user; not “everyone” but a concrete segment.

Specific painful problem with real cost

The problem has a visible cost in time, money, risk, or missed opportunity today.

Smallest complete outcome

There is a precise definition of “done” in which that problem is solved end-to-end for that user, without requiring several other unfinished pieces to be useful.

Standalone viability

It is realistic to imagine:

a simple landing page that promises only this outcome, and
a segment that would adopt it on its own and plausibly pay (or incur a meaningful switching / behaviour cost) for it, even if nothing else existed.

Informal version: “Would this make sense as a micro-SaaS if it had to?”

If the answer is no, then by this methodology it is not a feature. It is:

a sub-task of some other 1G,
“demo sugar”, or
something that should not be built.

The gate applies only to user-facing capabilities. Infrastructure, security, compliance and refactors are treated separately.

4. The Ground-Zero Rule

Every product has a ground-zero unit of value — the smallest action a customer must complete before anything else makes sense.

Examples

Booking product → the user must be able to apply.
Community → the user must be able to create a profile.
Task guide app → the user must be able to upload.
Notification system → users must be willing to give their email.

If this foundation does not work, nothing else can be validated.

This is why the methodology scopes MVPs around the ground-zero action first and always. This is not a design preference — it is engineering logic.

If Feature B depends on Feature A, you cannot build both at once and expect clean feedback.

You must build:

A → validate A → THEN build B.

When this step is skipped, you lose the ability to diagnose problems. For example, if you ship email + notifications together and something breaks, you cannot tell:

Did users refuse to give their email?
Did the email storage break?
Did the notification service break?
Did the notification logic interfere with email submission?

You lose all clarity.

The methodology avoids this failure mode entirely. Each version of the product is designed to answer a single yes/no question:

Does the core action work?
Do users adopt it?
Does it create value?

Only once this foundation is proven do we build the next layer. This approach works for any product, because it is based on dependency logic:

Build what everything else depends on first.
Validate it with real users.
Add the next layer of truth.

This ensures:

no wasted engineering,
clean, interpretable feedback,
predictable delivery,
zero ambiguity about what is working,
founders understand exactly what to build next,
products grow organically instead of chaotically.

5. 10G vs 1G: vision vs build unit

“10G” denotes statements like:

“Teachers need full classroom management.”
“Small practices need complete practice management.”
“Students need a housing platform.”

10G statements are useful as direction and narrative. The problem arises when a 10G vision is treated as the first unit of execution, leading to patterns like:

“The product only makes sense as a platform.”
“All of these modules must exist before users get value.”
“Therefore a 50–200k build is needed just to reach v1.”

That creates a single, large, loosely defined bet:

many features scoped together,
a long delay before real users touch anything complete,
ambiguous feedback if usage is weak.

1G does not reject 10G. Instead:

10G remains the long-term product.
The build unit becomes the 1G: one atomic outcome that passes the gate.

In practice this means:

Start from the 10G statement.
Break it into concrete pains with clear costs.
Define the smallest complete outcomes for each pain.
Apply the 1G gate to each outcome.
Select one 1G to build and ship.
Repeat, stacking additional 1Gs over time.

The 10G product becomes the accumulation of validated 1Gs plus the necessary support/glue, not a single massive first release.

6. Capital profile and hit-rate

Under a 10G-first mindset, people often converge on:

an “MVP” that is 8–20 features wide and 0–30% deep in each area;
an implied belief that 50–200k (or many months of a team) is required before anything is testable.

Under a 1G-first mindset:

An MVP is defined as 100% of one 1G, not 30% of everything.
The cost to reach meaningful validation often drops to something in the 4–10k range (or equivalent sweat + a small grant) for a single, sharply scoped 1G, followed by a decision on what to do next.

The total capital raised can still be large; the difference is in how it is deployed:

10G-first: one broad, entangled experiment.
1G-first: several narrow, explicit experiments that gradually assemble the 10G product.

Because every 1G is a complete solution to a single job:

each release tests a clear hypothesis (user, problem, outcome),
failure pinpoints a specific hypothesis rather than “the platform”,
success is anchored in a specific behaviour users adopt or pay for.

With the same total spend, multiple sharp 1G experiments yield a higher probability that at least one becomes something users truly care about, compared to a single, blurry platform experiment.

Having more engineers does not alter that logic:

Additional engineers increase throughput.
The methodology dictates whether that throughput is concentrated in one giant 10G bet, or spread across a portfolio of constrained 1G bets that together form the 10G product.

7. Support work, complements, and glue

Not all important work can or should pass the 1G gate. Examples include:

infrastructure, security, compliance, migrations, refactors;
complementary features that clearly and significantly increase the value or retention of an already validated 1G;
product “glue” that makes multiple 1Gs feel like a single coherent 10G product.

For this category, a different question is used:

Does this materially increase the expected value, robustness,
or coherence of one or more real 1Gs, and therefore of the 10G product they form?

If yes, it is treated as valid support work or glue. If no, it is considered noise.

The methodology does not claim every line of code must be independently “sellable”. It claims that only work justified as:

a 1G (passes the gate), or
support/glue that clearly raises the expected value of specific 1Gs,

should receive engineering capital in the early, uncertain stages of a product.

8. The operational question

In practice, the methodology reduces to repeatedly asking, for every proposed feature on a new product:

Ask this:

What is the smallest complete problem being solved here,
for which specific users,
that they would genuinely care enough about to adopt or pay for on its own –
and does this feature meet that bar?

If yes, it becomes a 1G building block of the 10G vision. If no, it is either support work for a different 1G, or it should not be built.