Relavo Designs

Relavo Design began with something I already knew about myself: I enjoy the part of a project that happens before the obvious work begins.

I like listening to an early idea, finding the part that has not been fully expressed yet, and helping someone understand what they may actually be trying to build. I like business concepts, design decisions, operating questions, and the moment when several disconnected thoughts begin behaving like one system.

I wanted a place where that kind of work could lead naturally into brand systems, web experiences, and creative frontend development.

At first, I imagined Relavo the way many contemporary boutique studios present themselves: a highly visual site, strong motion, parallax, polished transitions, and enough technical performance to prove what the studio could make.

There was nothing inherently wrong with that direction. I still care about expressive design and thoughtful motion.

But the more I looked at the experience from the other side, the less complete it felt.

A prospective client might arrive at an impressive website, watch the work move, read a few confident lines, and eventually reach a small inquiry form.

Then the useful information would disappear.

What kind of engagement did they actually need? What decisions had already been made? Which parts were still uncertain? What might change the cost? Was their budget even close to the kind of work being offered?

Those questions would be pushed into email.

The studio would ask for more context. The client would answer as well as they could. Someone would clarify the answer. A call might be scheduled. More questions would appear. After enough exchange, both sides might discover that the project, budget, timing, or expected level of involvement had never been aligned.

That process does not fail because people are careless. It fails because a small contact form is being asked to carry a complicated decision.

I did not want Relavo’s first useful act to happen only after someone submitted their name and waited for a reply.

The original site concept could have demonstrated visual skill. It would not necessarily have demonstrated how I think with someone.

That mattered more.

I was not trying to build another beautiful front door that opened into the same opaque conversation. I wanted the entrance itself to help a person slow the project down, separate what they knew from what they were assuming, and begin seeing the consequences of their choices.

Even if they never hired Relavo, they should leave with something more useful than a confirmation email.

That changed the standard for the entire project.

The website could no longer be treated only as promotion. It had to behave like the beginning of the service.

The repository preserves a version of that realization.

Relavo’s first verified Git history begins on June 28, 2026 with a working website scaffold. The following day, I stopped implementation and wrote a hard-reset charter. The project had begun moving into layout before its brand strategy, art direction, narrative, motion language, and operating model were mature enough to support it.

So the code stopped.

Research, positioning, documentation, and design became the work again.

That pause did not make Relavo less ambitious. It made the ambition more specific.

The goal was no longer to look like a studio capable of doing difficult work.

The goal was to design a better way for the work to begin.

I still needed a structure that could make that possible. I found the first useful clue away from the screen, during a hike in Mill Valley.

The first useful structure for Relavo came to me during a hike in Mill Valley.

I had been thinking about the uncertainty built into the usual studio inquiry. A prospective client often has to begin a conversation without knowing which details matter, how different choices affect the project, or whether the likely cost is remotely aligned with the budget they have in mind.

Then I thought about Apple.

When someone configures a computer, they do not have to email Apple and ask what additional memory might cost. They begin with a recognizable product, make a decision, and see the consequence. Storage changes. Memory changes. The price changes with them. A person can decide what matters, what can be reduced, and what belongs outside the current budget before reaching the final commitment.

The experience does not eliminate every question. It gives the questions an order.

That was the part that stayed with me.

I did not want Relavo to imitate Apple’s interface, language, or visual identity. I was interested in the behavior underneath it.

A person could begin with something understandable. Important decisions could appear gradually instead of arriving as one exhausting form. The reason behind a choice could remain close to the choice itself. When something changed, its effect could become visible. The current configuration could remain reviewable rather than disappearing into a private conversation.

Most importantly, the person could learn while deciding.

That seemed useful for design services, where prospective clients are often expected to describe a professional process they have never experienced before.

Instead of asking someone to arrive with perfect terminology, Relavo could help them develop the project in plain language. Instead of hiding every consequence until a proposal was written, the system could show which decisions were likely to add work, reduce work, introduce uncertainty, or require professional review.

The initial interaction could become a planning environment rather than a request for contact.

A website is not a laptop.

A computer can be assembled from known parts with established prices and tested dependencies. A brand-and-web project may begin with unclear goals, unfinished content, inconsistent materials, technical constraints, third-party services, creative judgment, and responsibilities that have not yet been assigned.

Two people can choose the same number of pages and still require very different projects.

So Relavo could not honestly place an exact price beside every answer and pretend the result was final.

The system needed to preserve uncertainty rather than decorate it with false precision.

A self-guided plan might produce a rough future build range when enough cost-driving information exists. That range would need visible assumptions and a confidence level. It would not be a quote, a reservation, or an acceptance of the project.

Professional Discovery would be a separate piece of work with its own reviewed scope and payable total. A build proposal would come later still, only after Relavo had enough information and capacity to make one responsibly.

That separation became fundamental:

guidance is not Discovery, Discovery is not a build, and an estimate is not a promise.

I later returned to the Apple comparison and documented the complete journey—from the public homepage through product education and into a controlled MacBook Pro configuration.

I recorded how the experience established relevance before configuration, revealed consequential choices in sequence, exposed dependencies, preserved an editable current state, offered contextual help, and delayed commitment until the configuration could be reviewed.

I also documented what Relavo should reject.

The visual system was Apple’s. The language was Apple’s. The commercial certainty belonged to manufactured products with bounded combinations. None of that could simply be transferred into a creative service.

The research was useful because it turned the hiking thought into something testable. It showed which principles survived outside their original context and where the analogy broke.

What survived was not a storefront.

It was a sequence:

understand the starting point → make one meaningful decision → explain its consequence → preserve the current record → review before commitment

That sequence gave Relavo a new direction.

The project no longer needed to behave like a studio website with a more complicated quote form.

It could become a guided planning room.

Once the configurable-product idea had survived its first round of scrutiny, Relavo’s original website concept no longer made sense.

The problem was not that the planned motion, parallax, or visual experiments were too ambitious. The problem was that they answered the wrong first question.

They began with what the studio could show.

The new direction had to begin with what a prospective client needed to understand.

That changed the role of the website. It could still communicate taste, care, and technical ability, but those qualities would need to appear through the usefulness of the experience—not only through how dramatically the page entered the screen.

Relavo’s first product was becoming the way a project was allowed to begin.

Turning the website into a planning environment did not mean replacing a five-field inquiry with a fifty-field questionnaire.

That would have moved the burden without improving the process.

Most people looking for a website do not know the internal language of brand strategy, information architecture, accessibility, content operations, integration planning, or responsive systems. They should not have to learn an agency’s vocabulary before they are allowed to explain what they need.

The questions had to remain plain enough to answer from real experience:

What are you trying to make possible? Who needs to understand it? What already exists? What feels unresolved? Which responsibilities can you carry, and where would you rather have help?

Some answers could affect the likely amount of work. Others could help establish direction without changing cost. Some would reveal a dependency. Some would expose a contradiction. Some would simply remain open.

The experience needed to know the difference.

In a normal form, a question appears, an answer is collected, and the person moves on.

Relavo needed the space between those actions.

If someone selected an option, the interface should be able to explain why that option might fit, what it could affect, what responsibility remained with them, and which part still required professional review.

The explanation should not be buried in a help center or delivered several days later in email. It should remain visibly attached to the decision that caused it.

That principle eventually shaped the motion system as well. A contextual explanation could move because the active relationship had changed—not because the page needed another animation.

The choice stays stable. The reason follows it. The consequence remains visible.

One of the easiest ways to make a planning tool look intelligent is to force every question into a clean result.

Real projects do not behave that way.

A person may know exactly who the work is for and have no idea how the content should be organized. They may have a logo they love but no broader brand system. They may know that something feels wrong without knowing whether the problem is visual, structural, technical, or operational.

Relavo could not punish that uncertainty or quietly convert it into a confident recommendation.

The system needed ways to say:

Leaving something open would not make the plan incomplete. It would make the record more honest.

This was the deeper shift.

The public experience would no longer end at “send inquiry.” It would begin creating a shared record before either side promised to work together.

The prospective client could see their thinking take shape. Relavo could eventually receive better context without repeating the same initial exchange. Decisions, reasons, assumptions, responsibilities, references, and open questions could travel forward together instead of being scattered across messages and memory.

That did not mean every visitor should be placed into the same process.

Some people want to think through the details themselves. Others have the idea and want a professional to help give it structure.

The planning room needed two doors.

Once Relavo became a planning room, another problem appeared.

The experience could not assume that every person wanted the same amount of control over the planning process.

Some people enjoy working through the details. They want to compare possibilities, understand what affects the work, and arrive at a clearer version of the project before speaking with anyone.

Other people know what they want to make possible but do not want to become their own strategist, information architect, or technical consultant to explain it.

Neither person is less serious.

They need different beginnings.

The first route is free and self-guided.

It is designed for someone who wants to think through the project in plain language, at their own pace, without beginning a sales conversation or paying to discover whether the process is useful.

A thoughtful first pass may take roughly sixty to ninety minutes. A more complex plan could take longer and continue across several sittings. The length is not hidden behind a promise that a meaningful project can be understood in five minutes.

The person begins with what they already know.

They can describe the goal, audience, current materials, desired outcome, possible pages or capabilities, content readiness, responsibilities, references, and the areas that remain uncertain. The system can explain why a question matters without expecting them to know professional terminology.

Nothing has to be invented simply to reach the next screen.

If an answer is not known, it can remain open. If the person wants Relavo to help determine something later, that can be recorded as well.

The result is not a hidden lead form disguised as a planning tool.

It is intended to become a Working Passport: a usable record built from the person’s own answers, decisions, sources, responsibilities, assumptions, and unresolved questions.

Beginning the route does not submit a project, authorize work, create professional recommendations, or require payment.

The second route begins much more simply.

It is for someone who has a real idea, practice, offer, or body of work but does not want to spend several hours deciding how professional discovery should be organized.

Relavo asks for enough context to understand the starting point: what the person is trying to create, why it matters now, what already exists, and where help is needed.

The intake is intentionally short. It should take minutes, not hours.

From there, Relavo can determine whether the project appears to fit, whether capacity exists, and what kind of professional Discovery would need to be scoped before deeper work begins.

This is the beginning of Full Works Discovery.

“Full Works” does not mean an instant promise to design and build everything. It means the client is asking Relavo to lead the approved discovery process rather than asking the client to perform it alone.

The professional work begins only after the Discovery scope, capacity, agreement, and payment are confirmed.

It would have been easy to make the self-guided path feel like a reduced option and Full Works feel like the real service waiting behind it.

That would have weakened both.

The self-guided route serves someone who values direct participation and wants a portable record before commitment. Full Works serves someone who values delegation and wants professional judgment applied earlier.

One begins with structured independence. The other begins with a request for professional leadership.

Both should make the next step clearer. Both should keep uncertainty visible. Both should respect the person’s time before Relavo asks for a commitment.

The important difference is who carries the discovery work.

And whichever door someone chooses, the project needs a record that can survive the conversation that follows.

Most inquiry forms are designed around what the business wants to receive.

The visitor answers the questions, presses submit, and watches the work disappear to the other side. They may receive a copy of the message or a polite confirmation, but the thinking itself has already been converted into a lead.

That felt wrong for a planning experience that could ask someone for real attention.

If a person spent an hour clarifying their project, the result should not exist only to help Relavo decide whether to contact them.

It should help the person understand the project too.

That became the Working Passport.

The Working Passport is intended to gather the useful context created during the self-guided route:

The value is not that every field becomes complete.

The value is that the project stops depending on memory.

A decision can remain connected to its reason. An open question can remain open without being lost. A future provider can see what was selected, what was deferred, and what still requires professional judgment.

The Passport does not announce that the project has been solved.

It shows the condition the project is actually in.

The distinction between a Working Passport and professional Discovery had to remain visible.

The self-guided route can organize what a person reports. It can provide definitions, show relationships, preserve assumptions, identify missing information, and explain the likely consequence of a selected choice.

It cannot honestly claim to have performed research that never happened.

It cannot verify an audience, validate a business model, clear a name, inspect a codebase, establish technical feasibility, create custom brand strategy, or guarantee that a project can be delivered for the rough range shown on the screen.

No person from Relavo has reviewed the Working Passport unless the visitor later chooses a route that includes human review.

That boundary is part of the artifact itself.

The record should say where it came from, which version it represents, and whether professional review has occurred. A self-guided Passport should never quietly mature into a professional recommendation because its layout looks polished.

The most important decision was that the Passport should not become valuable only after someone hires Relavo.

A person should be able to keep it, return to it, or eventually download it. They may use it to continue their own research, prepare for a later conversation, or explain the project to another provider.

That portability is not an accidental concession. It is the reason the artifact deserves to exist.

Relavo may have helped create the structure, but the person supplied the thinking inside it.

If they choose professional Discovery later, the record can develop. Assumptions may be tested. Research can be added. Decisions can be reviewed. The Working Passport can become a Human-Reviewed Passport with a different level of evidence and responsibility.

The two should never be confused.

One preserves the client’s current understanding.

The other records professional work that has actually been performed.

This changed how I thought about conversion.

The successful outcome of the planning route did not have to be a sale.

It could be a person realizing that the project was not ready, that the budget needed to change, that important source material was missing, or that they wanted to continue with someone else.

If the system helped them reach that conclusion with a clearer record, it had still done useful work.

Relavo could then ask a more honest question than “Are you ready to buy?”

It could ask what the person wanted to do with the Passport they had just created.

There needed to be more than one acceptable answer.

A planning experience can promise independence at the beginning and take it away at the end.

The questions feel useful. The progress feels personal. Then the final screen reveals what the system was designed to produce all along: a sales call, a locked report, or a payment screen that must be crossed before the work can leave with the person who created it.

Relavo could not call the Working Passport portable and then hold it behind the next transaction.

Finishing the self-guided route needed to produce three legitimate choices.

None would be selected in advance. None would be disguised as the only responsible next step.

The first ending is the simplest.

The person keeps the Working Passport for free.

They may need time. They may want to continue their own research. They may want to discuss the project with a partner, compare providers, wait for a better budget, or decide that the idea should not move forward yet.

The planning has already done its job by making the current condition of the project easier to see.

Choosing this route does not submit the project for review, begin a sales sequence, authorize work, or create a debt to Relavo.

The person leaves with the record.

That has to count as a complete outcome—not an abandoned checkout.

The second ending is for someone who wants professional work applied to selected parts of the plan.

The Working Passport may have revealed that the project needs audience research, clearer positioning, a content system, technical investigation, experience planning, or another area that cannot be resolved responsibly through self-guided questions.

The person can select the Discovery areas they want Relavo to undertake.

Unlike the rough future build range, the Discovery total is intended to become a real payable amount tied to an exact, versioned scope. The person should be able to understand what professional work is included before checkout.

Payment alone does not erase the operating boundaries. Capacity must be available. The Discovery order and agreement must be clear. The work begins only after those conditions are confirmed.

The result is professional evidence—not an automatic build commitment.

The third ending is for someone who believes the project may already be clear enough for Relavo to consider building it.

There is no immediate payment.

The person asks Relavo to perform a narrow review of the Working Passport for fit, capacity, visible blockers, and the minimum clarification required to decide whether an offer can responsibly be made.

That review is not free Discovery hidden under another name.

Relavo is not promising to research the market, solve unresolved strategy, establish technical architecture, or return a set of professional findings. The question is smaller: is there enough evidence to consider a build, and is Relavo able and willing to offer one?

The answer may be no. It may be not yet. It may identify the need for paid Discovery first. Or it may allow Relavo to prepare a separate build proposal.

A request is not acceptance. A review is not a proposal. A proposal is not a reserved production slot.

Each step has to earn the next one.

These endings changed the emotional shape of the experience.

There was no need to create urgency simply because someone reached the last screen. No countdown was required. No paid option needed to arrive preselected. No warning had to imply that the person was wasting their work by leaving.

The Passport could remain useful across all three routes because the record came before the commercial decision.

That order matters.

First, help the person understand the project.

Then let them decide what kind of relationship—if any—they want with Relavo.

Designing three honest endings also forced another distinction into the system. The numbers shown along the way could not all mean the same thing.

A rough range, a Discovery total, and a build proposal each belonged to a different moment, carried different evidence, and created different obligations.

They needed to be kept apart.

The original Apple connection began partly with price visibility.

Choose more memory, and the number changes. Reduce the storage, and it changes again. The relationship between the decision and its financial consequence is immediate because the product, components, and fulfillment system are already known.

Relavo could not offer that same certainty at the beginning of a creative project.

But hiding every number until the end would return the experience to the problem it was designed to solve.

The answer was not one smarter price.

It was three different monetary records, each appearing only when the evidence could support it.

The self-guided planning route may eventually show an indicative build range.

That range is based on visible cost-driving information: the likely amount of content, number and type of experiences, technical capabilities, integration needs, current material readiness, responsibility split, motion depth, and unresolved risk.

It should not change merely because a person selected a different aesthetic preference or answered a question that affects direction without adding work.

When the work changes, the range can change.

When only the taste changes, the number should remain still.

The range also needs to state its confidence. Early in the process, there may not be enough information to show one responsibly. Later, the system may have enough inputs for low, moderate, or higher confidence while still preserving important assumptions.

It remains guidance.

It is not payable. It does not expire like a proposal. It does not reserve capacity. It does not guarantee that Relavo will accept the project or that another provider would price the work the same way.

Its purpose is to help the person understand the likely financial shape of the project before either side pretends to have reached an agreement.

Discovery is a different commercial object.

At this point, the professional work itself can be bounded. The selected Discovery areas, deliverables, responsibilities, timing assumptions, and exclusions can be assembled into an exact versioned order.

Only then can the Discovery total become a real amount someone may be asked to pay.

That total pays for the approved professional Discovery work. It does not quietly become a build deposit. It does not promise that the project will move into production afterward. It does not make every unresolved idea feasible.

Capacity, agreement, and payment still have to align before work begins.

The greater certainty comes from the fact that the object being purchased is finally defined.

A build proposal belongs after human review.

By then, Relavo may have reviewed the Working Passport, completed paid Discovery, or received enough other evidence to understand the intended outcome, scope, responsibilities, dependencies, risks, timing, and operating requirements.

Only then can Relavo decide whether to make an offer.

The build proposal can state the actual proposed scope, commercial terms, schedule assumptions, milestones, exclusions, and deposit required to reserve the work.

It is not generated simply because a questionnaire reached completion.

It is a human commercial decision supported by a more mature record.

The three numbers form a progression, but they are not automatic upgrades of one another.

The rough range helps someone plan.

The Discovery total purchases a bounded piece of professional work.

The build proposal offers a separately reviewed production engagement.

Each number answers a different question:

Keeping those questions separate reduces the opportunity for false precision and late surprise.

It also creates a more respectful way to handle budget mismatch.

If a rough range moves beyond what someone can support, the system does not need to shame them, hide the number, or force the project forward. Scope can be reconsidered. Work can be phased. Responsibilities can change. The person can save the current record and return later.

The number is there to improve the decision—not to pressure it.

Designing that behavior required far more than drawing three price cards.

The system had to know which decisions affected cost, which only affected direction, when confidence had changed, what remained unresolved, and where automated guidance had to stop.

Before a line of production code could be trusted, the entire decision architecture had to be mapped.

Relavo has already had a website scaffold.

The first verified repository began on June 28, 2026. By the following day, I had stopped the implementation.

The pages could have continued. Components could have been polished. Motion could have made the early direction feel convincing.

But the code would have been answering questions the project had not earned the right to answer yet.

What was Relavo actually offering? Where did free guidance end and professional judgment begin? What did a completed planning record mean? Which actions created a commercial obligation? What happened when information was missing, contradictory, stale, or outside the system’s authority?

A functioning interface could still be structurally dishonest if those questions remained unresolved underneath it.

So the implementation stopped and the product moved back into research, documentation, mapping, and proof.

The project first had to be described independently of a screen.

The service model was separated into distinct stages: public orientation, self-guided planning, idea intake, Working Passport completion, paid Discovery, narrow build review, proposal, delivery, handoff, and the records that would need to survive between them.

Each stage created questions of its own.

Who has authority to act? What information exists at this point? What can be inferred, and what still requires a person? Which record becomes durable? What can the visitor edit? What happens when an upstream answer changes? What happens if the session is interrupted, the information is incomplete, the price confidence falls, payment fails, capacity disappears, or the project is not a fit?

Those were product questions before they were interface states.

The current service blueprint eventually grew into an E0–E23 architecture spanning the public entry, planning routes, Passport maturity, professional Discovery, build review, delivery, and future operations.

The public does not need to see every internal lane or rule.

The depth still matters because the visible experience is only trustworthy when the hidden handoffs agree with it.

The project uses versioned records to keep current decisions separate from historical exploration.

Research can influence the work without quietly becoming product law. A visual direction can be selected without turning its sample prices or placeholder copy into a public promise. An earlier route can remain useful evidence while a later owner-approved model replaces it.

That distinction protects the project from a common kind of drift: an old idea surviving simply because it appears in a polished document or finished-looking screen.

The current system establishes an authority order.

The service blueprint defines what must happen. The planning and commercial records define what each route is allowed to mean. The visual grammar defines how those relationships should feel. Figma expresses the current decisions. Historical prototypes remain evidence, not authority.

When the project changes, the governing record changes with it.

That allows a complex build to continue without asking memory—or an AI working inside the project—to reconstruct the entire system from scattered conversations.

FigJam became the place to see the service across time.

The map follows decisions and handoffs rather than collecting attractive screens. It shows the two ways to begin, the three endings after the Working Passport, the separation of paid Discovery from a possible build, and the different maturity of records as professional review is added.

It also reveals where the experience can break.

A person may leave and return. An answer may invalidate a later assumption. A rough range may not be ready. A reference may be unsafe or unusable. A project may exceed the responsible limit of automation. A paid route may be unavailable because capacity is closed.

Designing only the ideal path would make those conditions someone else’s problem during implementation.

Mapping them early made them part of the product.

There is still no current production implementation of the Relavo planning system.

That is an important status, not an embarrassing omission.

The responsive experience, component behavior, motion, accessibility expectations, pricing states, save model, Passport structure, and commercial boundaries are being reconciled before they become software.

Several decisions still require real production proof: identity, storage, privacy, security, retention, email behavior, payments, legal terms, operational capacity, accessibility, performance, and browser behavior.

Coding around guesses would not make those questions disappear. It would make them more expensive to correct.

Relavo is being designed so that implementation begins from an agreed system rather than turning the first implementation into the place where the system is discovered.

Once the journey had a governing structure, the next challenge was giving it a visual language capable of carrying that much information without feeling bureaucratic, cold, or overwhelming.

The product needed to feel precise without becoming a dashboard.

By the time Relavo’s service architecture reached Figma, the experience was carrying a great deal of information.

Choices had reasons. Reasons had consequences. Consequences could affect responsibility, timing, range confidence, or the need for human review. A person could leave something open, return later, revise an earlier answer, or discover that a later assumption was no longer valid.

The interface needed to preserve those relationships without feeling like enterprise software.

It could not become a dashboard filled with cards, status rails, and administrative chrome. It could not return to the original studio spectacle either. The work required enough energy to feel designed and enough restraint to remain understandable.

That tension produced the selected visual grammar: Guided Precision with a Continuous Thread.

The typography is designed around responsibility rather than decoration.

Instrument Sans carries recognition, decisions, actions, figures, identifiers, and concise status. It gives the interface its directness.

Atkinson Hyperlegible Next carries guidance, reasons, reassurance, recovery, and sustained reading. It gives the system room to explain itself without becoming dense or fragile.

One voice helps a person act.

The other helps them understand what the action means.

The distinction lets the interface become information-rich without making every sentence compete at the same volume.

The color system follows the purpose of the moment.

Black establishes arrival, orientation, and the places where financial or operating truth needs to feel unmistakable.

Paper carries reading, comparison, planning, and decisions. It is the long-form working surface rather than a decorative light theme.

Plum carries relationship: contextual explanation, continuity, handoff, and the threshold where automated guidance approaches human judgment.

Citron is deliberately scarce. It identifies one primary action, a meaningful change, or a value that is genuinely ready. If everything were bright, nothing would carry consequence.

These are not rotating themes.

They are roles inside the same system.

The selected composition keeps decisions, reasons, consequences, and review boundaries visibly connected.

On a wide screen, the choices may remain stable while a plum counsel surface aligns with the active row. When the selection changes, the explanation can move to the new relationship.

The motion has a job.

It tells the person that the meaning changed because the decision changed.

The prior explanation leaves. The same counsel realigns. The new reason arrives. Keyboard focus stays where the person acted. Rapid choices replace the current transition rather than building a queue of animation.

There is no bounce, parallax, cursor following, glowing trail, or motion added simply to prove the page can move.

Under reduced motion, positional travel disappears. The relationship remains understandable through order, labeling, and an immediate or near-immediate content change.

Desktop has enough room to place choices and counsel beside one another.

Tablet keeps that relationship only while the width remains comfortable. In portrait, the explanation moves beneath the option group instead of compressing into an awkward second column.

Mobile becomes one clear sequence:

choice → reason → consequence → review

At 320 pixels, the system still protects readable type, stable margins, unbroken identifiers, forty-four-pixel targets, and zero horizontal overflow.

The composition can change at every breakpoint.

The decision order cannot.

That is the purpose of the Continuous Thread. It is not a line drawn through the page. It is the promise that an explanation will never become detached from the choice that made it necessary.

The current Figma work proves that the grammar can carry the planned experience across desktop, tablet, mobile, motion, and pressure states.

It does not prove that the software has been implemented.

That distinction belongs inside the public record too.

Relavo currently exists in several different forms, and the differences matter.

There is a deeply specified service model. There is an owner-approved end-to-end blueprint. There are responsive Figma atlases, interaction proofs, component patterns, accessibility contracts, and a selected visual grammar.

There is also older working code: a private local Next.js and React visual prototype, along with a Processing and GLSL creative-runtime lab used to explore visual behavior.

Those artifacts prove that the project has moved beyond an idea.

They do not prove that the current client experience is live.

The current work defines:

This is substantial product work.

It is still design and specification.

The previous XPE implementation contains a private no-index visual prototype and a creative-runtime environment.

It proves that Relavo has already explored creative frontend architecture, modular application structure, local typography, testing tools, and Processing and shader-based visual systems.

It does not contain the current guided planning system.

The latest product model changed after that code was committed. The current two-door entry, Working Passport, three endings, money architecture, responsive atlases, and Continuous Thread direction live in newer governing documents and Figma.

The old prototype is therefore historical implementation evidence—not a preview of a client workflow that is secretly almost finished.

The current experience does not yet have production identity, authentication, cross-device drafts, database persistence, reminder email, enforced retention or deletion, a deterministic range engine, Passport export, Discovery checkout, payment handling, human-review operations, a client Project Hub, Notion automation, SiteFerry integration, or a public deployment.

No current client-facing planning workflow has been verified live.

That sentence protects the rest of the record.

Without it, polished Figma screens could allow a reader to assume that every interaction already exists. With it, the work can be evaluated for what it actually demonstrates: product reasoning, service architecture, visual-system design, responsive planning, and the discipline to keep evidence separate from aspiration.

Relavo’s public record should keep status visible in the same way the product keeps uncertainty visible.

Screens are labeled WIREFRAME, PROTOTYPE, IN DEVELOPMENT, or HISTORICAL STUDY.

An owner-approved working direction is not called production-ready. A designed behavior is not called implemented. A local prototype is not called a launch. A future client workspace is not presented as an existing service.

This is not cautious language added around the project.

It is the same operating principle the project was built around:

show what is known, preserve what remains open, and do not let presentation outrun evidence.

The distinction also creates room to explain where Relavo is intended to go next.

The public planning experience is only one side of the longer relationship. If a project moves forward, the same visibility could continue into the work itself.

The planning system solves the first handoff: how a person moves from an idea into a clearer project record.

If Relavo eventually works on the project, another handoff begins.

Research develops. Directions are compared. Typography and color move through discovery. Decisions are approved, reconsidered, or replaced. Source material arrives. Questions surface. The website begins to take shape across different screen sizes.

That work is usually scattered across calls, messages, design links, documents, and memory.

I want the client to be able to see the project becoming itself.

Relavo already has a private Design Lab, but it is important to describe it accurately.

The current lab is an internal proving environment.

It exists to test composition, typography, color, motion, responsive behavior, performance, creative runtime, and the conditions required before an experiment can influence a public experience.

An idea does not move from the lab into the website merely because it looks interesting. It needs a purpose, responsive evidence, critique, pass-or-fail criteria, and approval.

That environment is real.

It is not a client portal.

The longer-term idea is to create a tailored working room for each accepted project.

A client could see the current stage, recent progress, active questions, approved direction, and the decisions that led there. Font or style directions could be presented side by side with an explanation of what each would change. Approval moments could remain connected to the artifact and version that was actually reviewed.

The workspace could hold selected research, design studies, responsive proofs, meeting decisions, handoff material, and a legible history of how the project moved forward.

The goal is not to expose every internal experiment or turn the client into a project manager.

It is to make the collaboration easier to enter and the decisions easier to remember.

This client-facing Design Lab or Project Hub is a future operating direction. It is not yet a live product, governed initial-release feature, or included entitlement.

Some clients may benefit from a tailored Notion workspace or another operating system for content, responsibilities, approvals, and future maintenance.

That would be configured case by case.

Notion is not currently an automated Relavo integration, and every project would not need the same operating environment. The tool should follow the work rather than forcing the work to follow the tool.

The same principle applies after launch.

When a project’s content needs and technical structure align, Relavo may recommend SiteFerry as one possible content-management path. Another project may require a different system. Some may not need an editing layer at all.

SiteFerry is not bundled automatically with Relavo. There is no current shared account, data handoff, or live integration between the products. Any future use would require a separate fit decision, client choice, and commercial and privacy terms.

Relavo remains the place where the project is understood and designed.

SiteFerry may become one way an appropriate website continues operating after it has been delivered.

The longer-term opportunity is an in-house network of complementary systems.

Relavo can help shape and build the right experience. A visible client workspace can make the work easier to follow. SiteFerry can serve suitable content-maintenance needs. Optional operational systems can help the client continue after launch.

The connection is useful only if each part remains honest about its boundary.

No product should be included simply to increase the stack. No client should be routed into a system because the founder happens to own it. The recommendation has to follow the project’s actual needs.

That is the future working room I want Relavo to become: not a closed ecosystem, but a legible relationship in which the right tools remain connected to the reasons they were chosen.

Before that future can be offered, the first public release still has to cross its own gates.

The current founder target is to prepare an initial Relavo release in under a month.

That target gives the work urgency. It is not a public guarantee.

The responsive experience and operating model are still being locked in Figma. The current client workflow has not entered production implementation. Commercial, privacy, security, and operational decisions remain open.

Saying that clearly does not weaken the release.

It defines what has to become true before the word “launch” is useful.

The complete journey needs a final responsive lock across desktop, tablet, mobile, and 320-pixel pressure states.

The interaction model needs an approved prototype. Motion must be tested with focus behavior, rapid input, announcements, and reduced-motion equivalence. Long content, zoom, text spacing, keyboard use, screen readers, touch, localization, errors, and recovery need evidence beyond a static frame.

The visual direction also needs production decisions: final tokens, typography licensing, page-purpose assignments, component states, and originality review.

Those gates establish what should be built.

They do not build it.

Production work must still establish how a person is identified, how a draft is protected, where data is stored, how returning links work, when reminders are sent, how inactivity is calculated, how deletion is enforced, and what happens when any of those systems fail.

Pricing behavior needs an authoritative deterministic source. Payments, agreements, refunds, cancellations, capacity, and response promises need approved commercial rules. Privacy, security, and legal terms need to match the actual data and operating behavior.

The team operating the service must be able to honor the states the interface presents.

A button that says “request review” creates an expectation about who reviews it and when. A screen that says a draft is protected creates a security and retention obligation. A displayed Discovery total creates a commercial promise. A downloadable Passport creates questions of ownership, source material, and reuse.

These are not details to attach after the interface works.

They are part of what the interface means.

The full E0–E23 system does not need to appear publicly in one enormous launch.

An initial release can be narrower if its boundary is explicit and every included route works from beginning to end.

The correct first release is not the one with the most screens.

It is the smallest coherent experience that preserves the project’s promises: clarity before commitment, honest uncertainty, a useful record, visible human boundaries, and no commercial action that outruns its evidence.

Anything outside that boundary can remain documented future work rather than simulated completeness.

Relavo is not publicly live today.

It already demonstrates something I care about deeply: the ability to follow a familiar business process until its hidden friction becomes visible, then redesign the process as a connected system rather than decorating its surface.

The project moved from a flashy studio concept to a planning environment. From one quote idea to three different monetary records. From a final submit button to a portable Passport with three honest endings. From disconnected screens to a versioned service architecture. From decorative motion to motion that explains a relationship.

The same principle has governed every stage:

make the condition visible before asking someone to act on it.

That is the standard the release will be measured against.

Until the operating evidence meets it, the record will continue to say what Relavo actually is:

An active design and product-development system preparing to become a working practice.