One-Gram of
Tech (1G).

One-Gram of Tech (1G) is a methodology for building new software products where product–market fit is unknown.

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.

This methodology assumes:

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

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

The "Immediate Outcome". A feature is only a 1G if the reward for using it occurs in the same cycle as the effort required to use it. If the user must perform an action today for a reward in six months, it is not a 1G; it is a 10G dependency.

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

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

Every product has a ground-zero unit of value. This is not a design preference—it is Dependency Logic. If Feature B depends on Feature A, building both at once introduces technical noise. We isolate the foundation so your feedback is 100% interpretable.

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.

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?

"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.

1G does not reject 10G. Instead:

• Start from the 10G statement.
• Break it into concrete pains with clear costs.
• Define the smallest complete outcomes for each pain.
• 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.

The difference is in how capital is deployed:

Failure pinpoints a specific hypothesis rather than "the platform". Success is anchored in a specific behaviour users adopt or pay for.

The 1G-first mindset turns engineering time into Learning Capital.

Not all important work can or should pass the 1G gate. Examples include infrastructure, security, compliance, and refactors.

The methodology claims that only work justified as a 1G or support/glue that clearly raises the expected value of specific 1Gs should receive engineering capital in the early stages.