Decision-making

Software builds are full of decisions, most of them small. Below is how we split who decides what so the work doesn't stall on every fork.

Decisions Solagon makes without asking

Inside the agreed scope and design system:

• Implementation choices — which library, which pattern, how to structure a query
• Code-level decisions — naming, file organization, test coverage strategy
• Visual choices that follow the design system — exact spacing on a card, hover states, micro-interactions
• Performance and accessibility trade-offs — these have hard rules; we hold the line
• Cosmetic copy — placeholder labels, error messages, helper text
• Dependency upgrades — minor and patch versions
• Bug fixes — anything in scope that isn't working as specified

We just do these. We surface the result, not the deliberation.

Decisions we surface and recommend

When the answer would meaningfully shape the product or change the trade-off space:

• Major UX flows — sign-up flow, checkout flow, onboarding sequence
• Data-model decisions with downstream consequences — what gets denormalized, what's audit-logged, how multi-tenancy works
• Third-party tool selection — which CRM, which payment processor, which auth provider
• Trade-offs on scope vs. time vs. cost
• Dependency upgrades that could break things — major versions

For these, you get a written note: here's the question, here are the two or three viable answers, here's our recommendation, here's what we'd flag. You decide and we proceed.

Decisions we won't make for you

A few things we explicitly punt to you:

• Pricing and packaging of your product
• Legal copy (privacy policy, terms of service, licensing) — we'll coordinate with your counsel but we don't write it
• Brand voice and tone in non-trivial copy — we'll draft, you approve
• Customer-facing positioning — value props, headlines, what the product is "for"
• Strategic product decisions — what to build next, what features to prioritize beyond the agreed scope

We have opinions on all of these, and we'll share them if asked. But the call is yours.

How decisions get logged

Every meaningful decision (the second category above) ends up written down somewhere:

• In the scope document if it shapes the build long-term
• In a Linear / tracker comment if it's a specific feature or sprint
• In Slack/email with a clear "decided: X" note if it's tactical

This isn't bureaucracy — it's about the moment six months later when someone asks "wait, why did we go with the multi-tenant approach again?" and we don't have to relitigate.

When a decision needs to be reversed

It happens. A choice you made in week 2 looks different in week 8 with new context. We treat reversals like new decisions — surface the change, the cost, and our take. If it's a small change, we just do it. If it has cost or schedule impact, it goes through scope change.

We never pressure you to stick to a previous decision because "that's what we decided." If the right answer changed, the answer should change.

Where to go next

What we need from you → Code ownership & handoff →