The Plain Method
We don't begin with features, screens or technology. We begin by understanding what needs to change, deciding what deserves investment, and only then determining what should be built.
And once something ships, the work gives us something even more valuable: evidence.
How we think
Software can be beautifully designed, technically excellent and still solve the wrong problem. That's why Product Engineering at Plain doesn't begin or end with code.
We move through five connected responsibilities: understand the problem, decide where investment belongs, build with purpose, measure what actually happened, and turn that evidence into the next decision.
01 - Understand
Clients often arrive with a solution already in mind: a feature, an application, a redesign, an integration or a new product. Our first responsibility is to understand what sits underneath that request.
The depth of this stage depends on uncertainty and risk. Not every project needs weeks of discovery. Every project does need enough context to make the next decision responsibly.
02 - Decide
Understanding creates options. Decision turns those options into direction. We challenge assumptions, compare alternatives, consider evidence, technical implications, cost and expected value, and recommend what should happen next.
Proceed with the proposed direction.
Validate a critical assumption before committing further.
Solve the problem through a different direction.
The opportunity may be valid, but the timing isn't.
The available evidence doesn't justify the investment.
Plain can be paid to recommend that Plain shouldn't build anything.
03 - Build
When building is the right decision, Product, Design and Engineering move together. We translate direction into scope, experience, architecture and software, continuously checking that what we're producing still serves the problem we decided to solve.
This is not a fixed checklist. The product decides what it needs. When constraints require trade-offs, we prefer reducing scope over creating unnecessary technical fragility.
04 - Measure
Launch changes the type of information available to us. Before launch, we work with assumptions and evidence. After launch, we can observe how the product behaves in the real world.
Not every product needs the same metrics. Measurement should follow the outcome the product was intended to create.
05 - Learn
Evidence only becomes useful when it changes what we do next. We compare what happened with what we expected, identify what we've learned, and use that context to decide whether to continue, change, expand, simplify or stop.
The direction is working.
The idea is right, but something needs improvement.
Evidence supports further investment.
Reality suggests a different direction.
Further investment is no longer justified.
Learn returns us to Understand and Decide.
The loop
The Plain Method isn't a rigid sequence that every engagement must follow from beginning to end. A client can enter at different points depending on what already exists and what is already known.
Find the real problem.
Choose what deserves investment.
Engineer the right solution.
See what actually happened.
Turn outcomes into better decisions.
The next decision starts with better context.
Understand → Decide → Build → Measure → Learn
Measure / Understand → Decide → Build → Learn
Understand → Decide → Build
The method adapts to the product. The responsibility behind it doesn't.
Method meets engagement
Decide, Build and Evolve are the ways clients engage Plain. The Plain Method is the thinking that runs through all three.
Mostly: Understand → Decide, with investigation, challenge and planning where required.
Mostly: Decide → Build, with enough context to make Engineering purposeful.
Continuously: Measure → Learn → Understand → Decide → Build ↺
You don't need to move through all three services. The engagement depends on where your product needs us.
Explore our services →Working principles
We'd rather challenge a decision early than quietly build something we don't believe in.
More features and more code aren't measures of product success.
We make responsible trade-offs without treating engineering quality as disposable.
Good decisions require context, trust and honest collaboration.
We consider what today's decision means for the product tomorrow.
Where do we start?
You don't need to arrive with every answer. Tell us what you're trying to achieve, what already exists, and what you're uncertain about. We'll start there.