The principles behind what we build, how we work, and the advice we give.

A product carries the decisions of the company that makes it. What gets attention. What gets overlooked. What someone has to understand before they can begin. What happens when something goes wrong.

We believe those decisions deserve the same care as the thing we put into the world.

At Segern, Practice connects the products we create, our work with founders through Continuity, and the way we run the company itself. It brings strategy, design, technology, and business into the same conversation, because a decision in one changes what is possible in the others.

Our aim is to build things that matter and remain worth caring for. That requires ambition, but also the judgment to choose what deserves our time. It requires attention to detail, without making every detail a new invention. And it requires a business capable of keeping the promises its work makes.

The Source Codes are the short form of this thinking. The writing beneath them explains the choices, limits, and responsibilities each one carries. They are useful starting points, not instructions to stop thinking.

You do not need to work with Segern to use these practices. They are here to make our thinking useful and our standards visible.

The company is part of the design.

A thoughtful interface can still belong to a thoughtless service. Someone may finish a task easily, then struggle to understand a charge, recover their work, or reach a person who can help. The experience does not end at the edge of the screen.

We treat the surrounding decisions as part of the work. Pricing, support, language, internal tools, and the way responsibility passes between people all deserve consideration. So do the incentives that determine which problems receive attention and which are repeatedly postponed.

This does not mean redesigning everything at once or treating every problem as a visual one. It means looking far enough beyond the immediate request to understand what produces it. A confusing screen might need clearer language. It might also be exposing a business rule that no longer makes sense.

In our products, we want the experience and the company behind it to keep the same promise. In advisory work, we look for the decision beneath the symptom before recommending another deliverable.

Are we improving the experience, or decorating a problem we have left intact?

Name what should become better, and for whom.

A feature is not yet a reason to build. Neither is an opportunity to use a new technology, enter a fashionable market, or make something that looks impressive in a presentation.

We begin with a person and a situation. What are they trying to do? What gets in the way? What would become possible if we resolved it well? The answer gives the work a purpose against which scope, effort, and success can be judged.

We stay close enough to the people affected to let their experience correct our assumptions. Requests, complaints, observation, and commercial evidence each tell us something different. A request is worth understanding even when the requested solution is not the right one.

That understanding also helps us choose where to compete. We would rather serve a particular need with depth than collect features to appear comparable with everyone else. A narrow audience can still deserve a complete experience. Small scope should not mean leaving people to assemble the missing pieces themselves.

The useful change might be a better product. It might be a clearer decision, a simpler offer, or a project stopped before it consumes another quarter.

What should become meaningfully better if this work succeeds?

Make the thinking clear enough to question.

Writing gives an idea somewhere to become specific. It reveals whether we agree about the problem or have simply become attached to the same attractive words.

Before committing substantial effort, we describe the situation, the people involved, the intended change, and the limits of the work. We name what we know, what we assume, and what remains uncertain. We also make the recommendation clear enough that someone can disagree with it for a useful reason.

The document should be proportionate to the decision. A small change may need a paragraph. A consequential commitment may need alternatives, evidence, and a more careful account of the risks. Length is not the measure of thoughtfulness.

Writing does not make the outcome inevitable. Sometimes a sketch, prototype, or conversation is the quickest way to discover what we cannot yet explain. We use those discoveries to improve the account rather than forcing reality to follow the first draft.

For Continuity, clear writing makes advice easier to act on and revisit. For our products, it connects the people making decisions to the people who will live with them.

Could someone understand the choice, challenge the reasoning, and know what happens next?

Make fewer promises. Keep them better.

Every feature, service, tool, and recurring meeting asks for more than the effort needed to introduce it. It creates something to explain, coordinate, maintain, or eventually undo.

Before refining a solution, we look at what it asks us and other people to carry. Can we remove an unnecessary choice, combine overlapping work, use an established pattern, or solve the problem without creating another permanent thing?

Reduction is useful only when it makes the whole experience simpler. Removing a label can leave a person guessing. Combining two systems can make either harder to repair. A sparse screen is not an achievement if the missing clarity becomes someone else's work.

We aim for the smallest complete expression of the promise. The important journey should hold together, including the moments when something fails. Beyond that, additions need a reason stronger than availability or the desire to look comprehensive.

This is how restraint supports ambition. Fewer obligations leave more attention for the work that can make a meaningful difference.

What can we remove without asking someone else to absorb the cost?

Reduce the scope, not the standard.

Care becomes real when it changes a decision. It may mean improving the recovery path before adding another feature, rewriting an explanation that still leaves someone uncertain, or choosing a smaller release so the central experience can be resolved properly.

Some standards are not finishing touches. Correctness, accessibility, privacy, security, honest claims, and necessary recovery belong in the work from the beginning, in ways appropriate to its consequences. A beautiful first impression cannot compensate for a broken promise underneath it.

Beyond those essentials, we identify the details that define the experience. A particular interaction, a difficult transition, the structure of a recommendation, or the feeling of completing something may deserve unusual attention. Supporting details still need to work well, but they can often inherit a sound pattern rather than become separate design projects.

Unreasonable care is not unlimited elaboration or a demand for unreasonable working hours. It is the willingness to notice what would otherwise be dismissed, and to make room for what matters by declining what does not.

We stop refining when the agreed purpose and standards are met, and further work would contribute less than the next important need.

Which details carry the promise, and have we made room to resolve them well?

Make people more capable.

A product should help someone understand what is happening and act with confidence. Advice should help a founder make a better decision, not make them feel that good judgment belongs permanently to someone else.

We design for people who may be distracted, tired, unfamiliar with the system, or using it differently from us. Clear language, accessible interaction, meaningful choices, and a way to recover are part of respecting their circumstances.

Not every extra step is a flaw. Confirmation can be valuable before an irreversible action. An explanation can be worth the space it occupies. The question is whether the effort protects the person or merely serves the system at their expense.

We also make room for warmth, beauty, and small moments of delight. Usefulness does not require sterility. But expression should support the experience rather than demand attention someone came to spend elsewhere.

In Continuity, this means making our reasoning visible, listening carefully to disagreement, and being honest about where our knowledge ends. The relationship should strengthen the founder's ability to see and choose.

Does this leave the person with more understanding, choice, and control?

Know why it belongs.

Taste helps us choose between possibilities that may all be technically acceptable. It notices an awkward transition, an unnecessary feature, a sentence that sounds right but says little, or an opportunity to make something feel unmistakably itself.

That judgment needs more than the authority of the person expressing it. We explain what a choice contributes, what it costs, and why it suits this particular work. Examples help. So do counterexamples that show where a promising idea becomes excessive, confusing, or wrong for the situation.

References can sharpen our perception without becoming instructions to imitate. The useful question is what made a decision appropriate in its original context, and whether that reasoning holds here.

We take evidence seriously without pretending every worthwhile quality fits a metric. We also refuse to use taste as protection from feedback. When people consistently struggle with a decision we admire, the decision deserves another look.

A shared standard should make critique more precise and collaboration more generous. It should help people see the work more clearly, not learn to guess what will please the person reviewing it.

Can we explain this choice without relying on “it feels more premium”?

Make it real enough to be wrong.

Some questions cannot be answered through more discussion. A prototype can reveal an interaction that sounded natural but feels awkward. A conversation can expose an assumption hidden inside a strategy. A small release can show whether an improvement matters beyond the people who made it.

We choose the smallest credible test that could change the decision. We decide what we need to learn, how we will recognize it, and what exposure is appropriate before widening the audience or increasing the commitment.

The speed of the work should reflect the cost of being wrong. A reversible experiment can move quickly. A change to permissions, important data, or a promise people already rely on deserves stronger evidence and a safer way back. Calling something a prototype does not remove its consequences.

Learning and release are different judgments. A successful demonstration may justify another test without justifying production use. A negative result may justify stopping without turning the effort into a failure we need to disguise.

Mastery helps us choose the right level of fidelity, avoid preventable mistakes, and reach a useful answer sooner. It does not eliminate uncertainty.

What is the smallest safe encounter with reality that could change our mind?

Small teams. Clear ownership. Room to think.

We prefer small teams because we want the people making the work to remain close to the problem, to one another, and to the consequences of their decisions. Size is useful only when it adds capability the work genuinely needs.

That requires more than a low headcount. People need context, complementary skills, direct access to the work, and the authority to resolve what falls within their responsibility. We value curiosity and the ability to work across boundaries without losing depth of craft.

We protect focused time and keep coordination purposeful. Writing can replace an unnecessary meeting. A short conversation can replace a week of misunderstood messages. The format follows the need, rather than a rule that every interaction must be asynchronous or every question deserves a call.

When coordination grows, we first examine unclear ownership, competing priorities, and unnecessary work. Adding another process should not be our automatic response.

Calm does not mean low ambition. It means creating the conditions in which demanding work can receive sustained attention without depending on confusion, constant availability, or repeated rescue.

Have we given this work the people and conditions it needs, or simply made it busier?

Delegate the work. Keep the responsibility.

Delegation is useful when it expands what can be done without making the outcome harder to understand or trust. That applies to people, software, and AI.

Before handing over work, we make the purpose, boundaries, and expected evidence clear. For AI, this includes what it may access or change, what it must not do, when it should stop, and which actions need human approval. Confidence in an answer is not permission to act on it.

We distinguish a plausible suggestion from a verified result, and both from an authorized decision. Consequential work has a named human who accepts responsibility for the decision and the obligations it creates. Contributors should not have to guess who can resolve a disagreement or approve a change.

Using several agents does not by itself create independent verification. Their work still needs checks appropriate to the consequence, and someone accountable for responding when those checks fail.

In an advisory relationship, our role is equally explicit. We are responsible for the quality and clarity of our advice and the work we agree to carry out. The founder retains the decisions that belong to their company unless a specific responsibility has been expressly delegated.

Who can decide, what may be delegated, and what evidence is required before acting?

Making it is a choice. Keeping it is a commitment.

A useful experiment can quietly become an essential system. A document becomes the reference everyone trusts. A temporary workaround becomes the only way a customer can complete a task. Continued use can create obligations long before anyone formally accepts them.

We distinguish trying something from committing to maintain it. Before work becomes a lasting part of the company, we ask who relies on it, what it must continue to do, who will care for it, and what that care will require. We also consider whether an existing solution, a simpler arrangement, or a manual step would serve the need better.

Importance deserves review. It does not automatically justify permanence. A short-lived tool can have serious consequences, while a long-lived note may require very little oversight.

Anything people depend on needs an appropriate home, an accountable owner, a way to recognize failure, and a credible path to repair, replacement, or retirement. A review date is a moment to decide what happens next, not permission to delete something whose dependencies remain unclear.

Are we accepting the continuing obligation, or only enjoying the initial result?

The promise continues after the release.

A release changes the work. What was once a proposal becomes something other people may organize their time, information, or decisions around.

We plan for that transition. People should understand what has changed, how to use it, what its limits are, and where responsibility lives. We need a way to see whether the work behaves as intended and a proportionate way to respond when it does not.

For our products, stewardship includes reliability, support, recovery, and the care required as circumstances change. It also includes retiring things responsibly when keeping them would no longer serve the people who depend on them.

For Continuity, staying with the work means carrying forward the relevant context and revisiting advice as evidence changes, within the partnership we have agreed. A recommendation should not become untouchable because we made it. Nor should a client have to mistake an advisory relationship for an unlimited implementation or maintenance commitment.

Clear boundaries make sustained care possible. They establish who is responsible for what, what support exists, and how the next decision will be made.

What happens after someone begins to rely on this?

Care needs a viable business behind it.

The economics of the work shape the experience. An offer that requires more attention than its price can support creates pressure somewhere. A company that takes every opportunity can lose the capacity to serve the people who already trust it.

We consider commercial value, cost, support, and maintenance alongside design quality. We want customers to receive something worth paying for and the business to retain enough capacity to improve it. Profit, useful growth, and restraint can support the same long-term intention.

That means being selective about the products we build, the partnerships we accept, and the commitments we make. We would rather name an honest boundary than promise attention we cannot sustain. We also keep our ambitions open to expansion when evidence, demand, and capacity support it.

For advisory work, commercial judgment belongs in the recommendation. A beautiful direction that ignores the founder's runway, team, or ability to operate it is incomplete advice. The answer may be to build less now so the company can remain able to build what matters later.

Can this create worthwhile value without depending on promises we cannot sustain?

Make the work worth finding.

We want what we share to give someone a reason to trust our judgment. A working product, a useful explanation, or a clear account of a decision can do that more honestly than an impressive claim without anything behind it.

Proof is specific. It shows what changed, why a choice was made, and what the available evidence supports. It leaves room for limits and work still to be done. We distinguish what has been built from what has been tested, and both from what has produced a result in use.

Publishing is part of making good work available. We do not treat promotion as inherently shallow or expect useful things to be discovered by accident. We choose what to share, where it belongs, and whom it can help, rather than filling a schedule simply to remain visible.

We also protect the people and relationships behind the work. A useful lesson does not give us permission to disclose a client's private circumstances or make their experience more conclusive than the evidence allows.

The story should help people understand the work and make a sound decision about it. It should not have to conceal how the work was made.

Does the evidence support the story, and does sharing it serve someone beyond us?

What remains should keep earning its place.

A company accumulates more than products and revenue. It accumulates tools, exceptions, meetings, promises, documents, and decisions that once made sense.

We return to those commitments deliberately. What still serves a useful purpose? What could be combined? What has become harder to support than its value warrants? What are we preserving out of familiarity rather than need?

Subtraction requires care of its own. Before removing something, we understand who depends on it, what information must be kept, and how the transition will work. Removing a feature that someone values is a decision to explain and manage, not a celebration of a smaller feature count.

We preserve the reasoning worth carrying forward so that learning does not depend on one person's memory. The record should help someone make a better decision later, not grow into an archive of everything that happened.

Practice itself belongs under the same scrutiny. These principles should help us see, choose, and act. When a rule no longer does that, we should improve it rather than protect the wording at the expense of the work.

What are we still carrying that no longer deserves the obligation?

When principles pull in different directions

A principle matters most when following it costs something. Care can require more time. Learning can require releasing something unfinished. Simplicity can require a more sophisticated system behind the scenes.

We protect people and the obligations that cannot be traded away first. Then we protect the useful outcome. Within those boundaries, we look for the least burdensome way to achieve it and concentrate craft where it makes the greatest difference.

When a real tension remains, we name it. We record the choice, the person responsible, the cost we are accepting, and what would cause us to reconsider. We do not resolve a conflict merely by finding a more attractive sentence for it.

Understand the promise before committing the effort.

The foundation makes the work clear enough to begin and honest enough to revise. It should establish the problem, the person affected, the intended outcome, and the constraints that give the decision its shape.

Our Foundation One-Pager brings those elements together. It describes the job to be done, the audience and context, and how the experience should feel. It names success, non-goals, risks, and one accountable steward. Evidence and unresolved assumptions sit beside the recommendation rather than being buried in a supporting document.

A steward is the person responsible for keeping the purpose and decisions coherent. They do not have to perform every task, but they do have to know who can decide, how progress will be judged, and when a change requires another conversation.

For a product, the one-pager might define the first complete journey we need to test. In Continuity, it might define a decision about positioning, scope, or investment, with viable alternatives and the evidence needed to choose between them. Both need a finish line. Neither needs a larger document than the decision can justify.

Give the work a rhythm and the next decision a date.

Direction becomes useful when it changes what happens next. We connect a longer intention to a small amount of active work, with a clear outcome, an owner, and a point at which we will review what reality has taught us.

We call a focused two-week work cycle a Story. Several Stories sit within a Chapter, a longer period of roughly four months that holds the broader intention. These are planning rhythms, not promises that every problem or partnership fits the same schedule.

We look one to three Stories ahead without pretending distant work is already certain. A useful early sequence may establish proof, strengthen reliability, and then reduce the ongoing effort of operating the result. Those are possible needs to address, not a compulsory order when the evidence calls for something else.

Each Story identifies the change we intend to make, what would count as success, the dependencies, the risks, and the steward. The review date creates a decision point. We may release, continue a bounded test, change direction, pause, or stop. Being explicit about that outcome is more useful than producing something merely to satisfy the calendar.

Keep the standard inside the work.

Before building starts, the people involved should understand the primary outcome, their responsibilities, and what done means. The quality checks belong alongside the plan, not in a final inspection that discovers the foundation was wrong.

We define the evidence required for the deliverable and its consequences. A product change may need tests for ordinary use, failure, recovery, and accessibility. A strategic recommendation may need traceable sources, viable alternatives, explicit assumptions, and a clear account of the tradeoff. An agent needs bounded permissions as well as a task.

We review the work in a form that can expose what matters. Screens alone cannot establish that an interaction feels right. A persuasive document cannot establish that its claims are true. Where the medium affects the judgment, we work in that medium early enough to learn from it.

The definition of done records the steward, acceptance conditions, necessary artifacts, relevant edge cases, verification, and the decisions that need to remain understandable later. Open questions stay visible. A finished draft, a verified implementation, and an authorized release are different states of the work.

Put something useful into contact with reality.

Delivery makes the work available for its intended use. That may be a released product change, an agreed decision with clear next steps, or an experiment whose result changes what we do next.

The handoff should explain what changed, why it matters, whom it helps, and how to use it. It should also make known limits and the next step clear. Where a short walkthrough helps, we provide one. We do not force every recommendation into software release notes.

We compare what happened with what we expected. We look at what worked, what surprised us, where effort was lost, and what deserves to become a repeatable practice. We choose a concrete improvement rather than turning every reflection into a new process.

Useful learning includes evidence that a direction should not continue. We record that result honestly, preserving the distinction between a question answered and a benefit achieved. Delivery closes one loop and gives the next decision better ground to stand on.

Make continued use an owned responsibility.

Before something becomes part of everyday work, we establish who owns it, what people can expect, and how it will be cared for. The amount of documentation and oversight should reflect what could happen if it failed.

For a product or system, the ownership record includes its support route, expected service level where relevant, known issues, monitoring, update rhythm, and recovery plan. We make the conditions for replacement or retirement visible too. Important state and dependent users should not be discovered only when it is time to shut something down.

Early reviews check behavior, address sharp edges, evaluate whether the intended outcome is appearing, and consolidate what we have learned. Our product handoff can use checkpoints on days one, seven, fourteen, and thirty, adapted to the nature of the release. Those dates do not replace a response when a serious problem appears sooner.

For Continuity, the equivalent is a maintained account of the decision, its reasoning, the responsible people, and the evidence that would justify revisiting it. Follow-through stays within the agreed relationship. The purpose is to preserve useful context and clear responsibility as circumstances change.

Practice shapes which problems we take on, how small we can make the first complete experience, and what standard we hold before someone depends on it. It continues through the economics, support, improvement, and eventual retirement of the work.

Our products are a place to put these principles under pressure. The value is not that the principles guarantee a result. It is that they make our choices deliberate and our standards open to examination.

Continuity is our ongoing advisory offering for founders who want considered judgment across product, design, technology, and business.

The work begins with the decisions that matter in the founder's actual circumstances. We help clarify the problem, examine alternatives, choose what deserves attention, and connect a recommendation to the next useful action. Sometimes that means shaping what to build. Sometimes it means changing the offer, reducing scope, or deciding not to proceed.

The value of continuity is the context that carries forward. Advice can be revisited against what happened, rather than starting again with a disconnected opinion. The founder remains responsible for their company, and our responsibilities are made explicit in the partnership.

The principles are public. The work together is in applying them to a particular company, making difficult tradeoffs, and returning to the consequences of those choices.

We apply the same thinking to Segern's tools, partnerships, spending, communication, and ways of working. A process should earn the attention it consumes. A new commitment should have the capacity behind it. A small company should not accumulate the obligations of a much larger one by accident.

We keep a record of the decisions worth remembering. Story reflections inform Chapter summaries, and the year's most useful lessons become part of a longer account we call the Book. Its purpose is to preserve judgment and context, not to turn running the company into a documentation project.

Begin with one real decision

Choose a piece of work that matters now. Write who it serves, what should change, and what must remain true. Name the uncertainty that could alter the decision, the smallest useful next step, and the person responsible.

Define what would count as done and when you will review the result. Then do the work, examine what happened, and decide what deserves to continue.

Practice should make the next decision clearer.