// about

One accountable builder from scope to operation.

Norseson is a one-person product and engineering studio. The person who helps define the system is the same person responsible for building it, verifying it, documenting it, and answering for the result.

Continuity risk

The model reduces handoffs. It also creates key-person dependency. That risk must be handled through customer control, visible ownership, documentation, bounded access, and deliberate handover—not hidden behind the benefits of staying small.

Discuss a project

// direct_accountability

One person keeps the context and owns the decisions.

Customers are not repeatedly transferred between sales, project management, and engineering layers. Decisions remain attributable, and constraints or exclusions are recorded instead of being hidden in a handoff.

Discovery

Understand the operating problem, users, current state, and evidence.

Architecture

Make constraints, dependencies, ownership, and irreversible risks visible.

Implementation

Build the smallest defensible slice without hiding partial completion.

Verification

Run agreed checks and report a failed check as a failure.

Launch

Require approval before irreversible production actions and record launch state.

Continue or hand over

Keep ownership explicit or prepare the system for another competent engineer to review.

Boundary

Fewer handoffs preserve context; they do not create unlimited availability or prevent mistakes. Capacity is intentionally limited, and concurrent engagements must be controlled.

// why_small

The studio stays small to keep responsibility visible.

What the model improves

  • Direct communication with the person making technical decisions.
  • Less information loss between discovery, delivery, and operation.
  • Clear ownership of estimates, trade-offs, exclusions, and mistakes.
  • Fewer hidden organisational layers between a problem and a decision.
  • Bounded technical decisions made with the full engagement context.

Where the model stops fitting

  • Norseson cannot accept unlimited concurrent work.
  • Work and start dates must be scheduled realistically.
  • Some projects require specialist capability outside the agreed model.
  • A one-person studio is not appropriate for every engagement.
  • Large support rotations or continuous incident coverage require a different operating model.

Where required capability or coverage sits outside the agreed model, that limitation should be identified before work begins rather than concealed after commitment.

// engagement_operation

How an engagement moves from uncertainty to an explicit state.

  1. 01

    Understand the operating problem

    Start with the people, workflow, system state, and business consequence—not a preferred technology.

  2. 02

    Identify constraints and irreversible risks

    Record dependencies, assumptions, exclusions, access boundaries, failure conditions, and decisions that are hard to reverse.

  3. 03

    Define a bounded first slice

    Choose a reviewable outcome that can establish evidence before wider commitment.

  4. 04

    Build and verify

    Implement against explicit acceptance conditions and make failed or incomplete checks visible.

  5. 05

    Make launch state explicit

    Confirm approval, account ownership, data paths, recovery limits, and who is responsible after release.

  6. 06

    Continue ownership or prepare handover

    Agree the next operating boundary or identify what another engineer still needs to investigate.

// capacity_and_communication

Capacity and communication have explicit boundaries.

Limited concurrency

Overlapping commitments are controlled so capacity is not hidden through degraded delivery.

Realistic start dates

Start timing follows current commitments, access, scope, and dependencies—not a generic promise.

Explicit scope change

Expansion requires agreement on priorities, consequences, and what moves or stops.

Agreed communication

Channels, cadence, approval routes, and responsibility are established at the start.

Support windows, response expectations, release cadence, and escalation paths are agreed for each engagement. They are not assumed, and availability outside those boundaries is not implied.

// customer_control

The customer should not be trapped inside the vendor relationship.

The preferred engagement model keeps business-critical accounts, assets, data, and recovery authority visible and transferable. Page copy cannot enforce ownership by itself; the actual account and access model must be agreed and verified for each engagement.

Preferred model

Customer-controlled

  • Domains and DNS
  • Source repositories
  • Production hosting and databases
  • Business data and export access
  • Billing, email, analytics, and app-store accounts
  • Third-party vendor accounts
  • Design and content source assets
  • Secrets ownership and recovery access

Agreed access

Norseson-operated

  • Agreed implementation and release work
  • Technical configuration under delegated access
  • Maintenance and investigation inside the agreed support boundary
  • Technical documentation and risk records included in scope

Explicit decisions

Shared responsibility

  • Product priorities and acceptance decisions
  • Access grants and production approvals
  • Data handling, retention, and lawful use
  • Release timing, operational readiness, and rollback decisions
  • Support expectations and escalation paths

// continuity_and_handover

Key-person dependency needs an operating response.

A one-person studio creates a real failure mode: if the relationship pauses or ends, the customer can lose access or operating knowledge. The intended continuity model is to reduce that dependency through customer control, visible ownership, inspectable records, and an explicit transition state.

  • Keep source in an accessible version-controlled repository.
  • Record consequential architecture and product decisions.
  • Document the deployment path and environment requirements without publishing secret values.
  • Make infrastructure and vendor-account ownership visible.
  • Identify data export, backup, recovery, and rollback paths where the scope requires them.
  • Keep known limitations, outstanding work, and unresolved incidents visible.
  • Review handover state before an engagement ends rather than assuming it is complete.

Boundary

This is a preferred engagement model, not a guarantee of immediate takeover. Norseson does not claim a standing backup engineer, escrow, automatic succession, or that another engineer can continue without investigation.

Depending on the engagement, handover may include:

  • Repository and required access
  • Architecture and system-state summary
  • Deployment and release instructions
  • Environment-variable inventory without secret values
  • Infrastructure and vendor-account inventory
  • Data, backup, rollback, and recovery notes
  • Known incidents, limitations, and unsupported assumptions
  • Current backlog, pending migrations, and responsibility map
  • Monitoring locations where monitoring is in scope

Handover depth depends on scope. Missing documentation must be identified rather than silently assumed, and a handover does not guarantee that the next engineer needs no investigation.

// existing_system_takeover

Takeover begins by establishing state, not changing production.

  1. 01Verify repository access.
  2. 02Verify deployment and environment access.
  3. 03Identify who controls production and can authorise change.
  4. 04Reproduce the current build.
  5. 05Locate data stores, infrastructure, and vendor dependencies.
  6. 06Review environment requirements without exposing secret values.
  7. 07Record known failures, missing evidence, and unsupported assumptions.
  8. 08Define one safe first change.
  9. 09Preserve rollback and handover paths.

No immediate mutation should occur before access, ownership, build, data, and recovery state are understood. An undocumented system cannot safely be treated as understood.

Missing credentials, unknown infrastructure, or an unreproducible build may block takeover. Stopping is a valid outcome when the system cannot be changed safely.

Embedded Product PartnerTechnical Review

// working_principles

Principles for work that remains inspectable.

Fail explicitly

A failed check, blocked action, or incomplete release remains visible.

Record important state

Decisions, ownership, assumptions, exclusions, and unresolved risk should be attributable.

Build bounded slices

Each slice should be reviewable, verifiable, and reversible where practical.

Prefer inspectable technology

Known operating behaviour matters more than novelty for its own sake.

Make irreversible actions deliberate

Deletes, migrations, sends, payouts, and production changes require an explicit decision.

Keep ownership visible

The business should know who controls each account, asset, approval, and recovery path.

Preserve an exit path

Continued work should improve transferability rather than deepen hidden dependency.

// establish_the_state

Bring the product, system, or operational problem.

The first task is to establish what exists, who owns it, what can fail, and what should happen next.

Discuss the system