What are the five stages of the Valaryn methodology?

Research, Design, Build, Refine, and Scale. Research identifies a real problem, Design decides the smallest complete solution, Build ships it to real households, Refine corrects it using actual usage, and Scale grows only what has proven useful.

How do you decide which features to build?

By how many households hit the underlying problem and whether it blocks success in the first week. Requests are grouped by problem rather than counted as feature votes, because a request describes one possible solution, not the need behind it.

What does user-centered design mean here?

Designing from observed routines rather than a feature list. Practically it means building the first screen first, testing wording by reading it aloud, and rejecting anything that requires explanation before it becomes useful.

How is customer feedback collected?

Through conversations with households, direct in-product feedback, and behavioral signals like where people abandon setup. The point where users stop is usually more informative than what they ask for.

Why release small updates instead of big ones?

Small changes are easier to evaluate and reverse, and they are less disruptive to families who have settled into a routine. Large releases bundle good and bad changes together, which makes it hard to tell what worked.

How did this process shape PowerPlanMatch?

Research revealed that people wanted confidence rather than the absolute lowest rate. That reframed the product from a ranked price list into a plain-language twelve-month cost projection based on a household's real usage.

How did it shape The Chef's Cookbook?

Testing showed people reacted to a relative's handwriting before the recipe text, so the design keeps the original scanned card alongside the typed version — a decision that made the interface less clean and the product far more meaningful.

Where does Accend Web & Commerce come from?

It grew out of the Build stage. The fast, accessible, well-performing foundations we built for our own products turned out to solve the same problem for organizations that need modern websites and commerce experiences.

Research. Design. Build. Refine. Scale.

Every product we ship moves through the same five stages, and none of them are optional. Here is what actually happens in each one — and why customer feedback outranks internal opinion.

Most software gets built backwards. Someone has an idea, a team builds it, and then everyone hopes people want it. It is a reasonable way to produce interesting technology and a poor way to produce useful products.

We use a five-stage process — Research, Design, Build, Refine, Scale — and the value is less in the names than in the discipline of not skipping any of them. Every one of our products went through all five, and each stage killed ideas we liked.

Stage 1: Research

Research means talking to the people who have the problem, before we have anything to show them. Not a survey. Conversations, in kitchens and living rooms, about what is actually irritating.

The rule we hold to is that we are looking for problems, not validation for a solution. It is very easy to describe an idea to someone, get polite enthusiasm, and mistake that for demand. So the questions stay about the present: what did you do last week about this, how long did it take, what did you try before, and what stopped you.

What research actually produced

PowerPlanMatch is a clean example. We started with the assumption that people wanted to find the absolute cheapest electricity plan. What we heard repeatedly was different: people wanted to stop worrying that they had been fooled. The advertised rate never matched the bill, and the emotional problem was distrust rather than price. That reframing changed the product from a ranked price list into a plain-language projection of what a plan will likely cost across a year.

With HomeHalo, research told us that parents were not asking for more control. They were asking to stop having the same argument every night. The winning feature turned out to be a schedule, not a dashboard.

Research ends when we can state the problem in one sentence that the people who have it would recognize as their own.

Stage 2: Design

Design is where we decide what not to build. That is the majority of the work.

We start with the smallest version that would genuinely help — not a stripped-down demo, but a complete solution to a narrow problem. Narrow and complete beats broad and half-finished every time, because a household will adopt a tool that reliably does one thing and will abandon one that partially does five.

User-centered design in practice

Two habits do most of the work here. First, we design the first screen before anything else, because the first screen is the product for most people. If the most important information is not immediately visible, no amount of depth below it helps.

Second, we test language as seriously as layout. Screens get read aloud in review. If a sentence needs explaining, it gets rewritten — "content filtering enabled at network level" becomes "adult sites are blocked on every device in your home." Plain language is not a simplification of the product; for most people it is the product.

The Chef's Cookbook design phase produced one decision that shaped everything after: keep the original photograph of a recipe card next to the typed version. Every early tester reacted to the handwriting before the text. A cleaner interface without it would have been technically better and emotionally wrong.

Stage 3: Build

Building is where scope discipline gets tested, because this is the stage where good ideas arrive and want to be added immediately.

Our approach is to ship the narrow version to real households early, even when it feels uncomfortably incomplete. Internal debate about whether a feature matters can run for weeks; two weeks of actual usage settles it. So we keep a parking list, build the core, and get it into homes.

Quality standards that do not get traded away

Speed has limits. Four things are non-negotiable regardless of schedule: accessibility, performance on mid-range and older devices, clear failure behavior, and privacy defaults. These are hard to retrofit and expensive to ignore. A family with an older Android tablet is a real user, not an edge case, and a product that only performs well on new hardware is not a family product.

Accend Web & Commerce grew directly out of this stage. Building fast, accessible, well-performing sites for our own products produced foundations worth offering to organizations facing the same problem.

Stage 4: Refine

Refining is where real usage tells us what we got wrong, and it always does. This stage is the reason the earlier ones stay honest.

The most useful signal is not a feature request. It is the point where people stop. If forty percent of new users abandon setup at the same screen, that screen is the problem — not the users' patience. If nobody ever opens a section we spent a month on, the answer is usually to remove it, which is harder than it sounds.

How we handle customer feedback

We take requests seriously without taking them literally. A request describes a desired solution; underneath it is a problem worth understanding. "Add more report types" often means "I cannot tell at a glance whether anything is wrong," which is solved by a better summary rather than more reports.

Practically, we group feedback by underlying problem, count how many households hit it, and weight anything that blocks first-week success above everything else. A feature that delights advanced users but confuses new ones is a net loss.

Continuous improvement here means small, frequent releases instead of large seasonal ones. Small changes are easier to evaluate, easier to reverse, and less disruptive to a household that has settled into a routine.

Stage 5: Scale

Scaling comes last, and only once a product has proven it makes something genuinely easier. Growing a product that has not earned it just multiplies a bad experience.

For us, scaling has two meanings. The technical one is straightforward: making sure performance, reliability, and support hold up as usage grows. The product meaning is more interesting — extending carefully into adjacent problems the same household already has. Recipe preservation leading naturally into meal planning and shopping lists is a good example. Both problems belong to the same person on the same evening.

The constraint at this stage is that new capability must not complicate the original experience. Every addition gets checked against the setup flow and the first screen. If a new feature makes the first five minutes harder, it goes behind a door rather than onto the main surface.

Why the order is not negotiable

Each stage protects against a specific and expensive failure. Skipping Research means building something well-made that nobody needs. Skipping Design means shipping complexity that has to be maintained forever. Skipping Build discipline means a product that is late and unfocused. Skipping Refine means shipping your own assumptions permanently. Skipping the patience before Scale means growing a problem instead of a solution.

The process also means we say no often, including to features our own team wanted. That is the cost of shipping products that stay simple after two years, and it is the main reason our four products share a design language and a release rhythm rather than drifting apart.

Innovation, in our experience, is not mostly invention. It is the discipline of continuing to remove things until what remains is obviously useful.

Frequently asked questions

What are the five stages of the Valaryn methodology?: Research, Design, Build, Refine, and Scale. Research identifies a real problem, Design decides the smallest complete solution, Build ships it to real households, Refine corrects it using actual usage, and Scale grows only what has proven useful.
How do you decide which features to build?: By how many households hit the underlying problem and whether it blocks success in the first week. Requests are grouped by problem rather than counted as feature votes, because a request describes one possible solution, not the need behind it.
What does user-centered design mean here?: Designing from observed routines rather than a feature list. Practically it means building the first screen first, testing wording by reading it aloud, and rejecting anything that requires explanation before it becomes useful.
How is customer feedback collected?: Through conversations with households, direct in-product feedback, and behavioral signals like where people abandon setup. The point where users stop is usually more informative than what they ask for.
Why release small updates instead of big ones?: Small changes are easier to evaluate and reverse, and they are less disruptive to families who have settled into a routine. Large releases bundle good and bad changes together, which makes it hard to tell what worked.
How did this process shape PowerPlanMatch?: Research revealed that people wanted confidence rather than the absolute lowest rate. That reframed the product from a ranked price list into a plain-language twelve-month cost projection based on a household's real usage.
How did it shape The Chef's Cookbook?: Testing showed people reacted to a relative's handwriting before the recipe text, so the design keeps the original scanned card alongside the typed version — a decision that made the interface less clean and the product far more meaningful.
Where does Accend Web & Commerce come from?: It grew out of the Build stage. The fast, accessible, well-performing foundations we built for our own products turned out to solve the same problem for organizations that need modern websites and commerce experiences.

Valaryn Technologies Editorial Team

Product, design, and engineering team

We build software that simplifies everyday life for families, consumers, and growing organizations. Our writing comes from the same research and customer conversations that shape HomeHalo, The Chef's Cookbook, PowerPlanMatch, and Accend Web & Commerce.