How we work · From your side of the tableWebsites · CRM · Automation

You should never have to ask where your project is.

Good projects feel clear before they feel fast. You’ll know what we’re doing, what we need from you, what’s been decided and what’s in scope, without chasing anyone for it.

Hey, quick one. Any update on where things are with the site?The message you shouldn’t need to send

Already answered ↓
Halden Studio · Website + CRMProject status
Where it is
Phase 4 of 8 · DesignSitemap and pipeline approved
Your move
Homepage feedback, in one roundComments on the review link
Our move
Workflow specs for follow-up
Blockers
None
Fictional project · the kind of view you’ll always have
One project, start to finish

Watch the project move. The status keeps up.

Follow one fictional project through eight phases. As you scroll, the status board updates: whose move it is, what’s been decided, what’s still open and what’s in scope.

  1. Phase 01

    Understand

    What are we actually solving?

    We start with the business, not the tool. Before anyone opens GoHighLevel or a design file, we look at how the business works today and mark where it breaks.

    Current state, marked upExample
    • Website form → personal inboxhandoff breaks here
    • Phone lead → whoever answersowner?
    • Spreadsheet and CRM, both “the truth”two sources
    • Follow-up → memoryno next action
    Gate: the problem is agreed
  2. Phase 02

    Map

    What happens today, and what should?

    The journey, the process and who owns each step, current and future side by side. This is where most of the real decisions start to show up.

    Side by sideExample
    Today

    Form goes to an inbox. Someone replies when they see it. Nobody owns the follow-up.

    Should be

    Form books a call, creates the record, assigns Dana and starts the follow-up.

    Gate: journey and ownership agreed
  3. Phase 03

    Decide

    What are we building, and what aren’t we?

    Scope should be visible before work starts. Pages, stages, workflows and priorities get written down, along with what’s not included, stated plainly.

    Scope of work · structureIllustrative
    • IncludedPage by page, workflow by workflow
    • ExcludedStated plainly
    • AssumptionsWhat we’re taking as true
    • DependenciesWhat it needs from others
    • ResponsibilitiesWhat you provide or do
    • AccessAccounts and permissions
    • DeliverablesIncluding documentation
    • PricingAgreed before work begins
    • Change processHow new requests work
    Gate: scope and priorities confirmed
  4. Phase 04

    Design

    Does the structure hold up before we build it?

    Different work, different things to get right. The principle is the same: structure and logic first, everything else after.

    What we design firstBy project type
    • WebsiteStructure before decoration. The sitemap is a decision system. Website Design
    • CRMStages that describe what’s actually true, with a named owner. CRM & Pipelines
    • AutomationLogic before workflows, including what happens when it fails. Systems & Automation
    Gate: structure and logic approved
  5. Phase 05

    Build

    Does the build match what was agreed?

    The project shouldn’t live inside someone’s memory. Decisions, blockers and next steps go into a log you can read, so a decision that matters later exists somewhere besides a meeting.

    Project logExample entries
    1. #014DecisionBooking on every service page.
    2. #015BlockerWaiting on calendar access. Cleared.
    3. #016StatusPipeline configuration complete.
    4. #017ChangeService-area field added. Approved on record.
    Gate: matches design and scope
  6. Phase 06

    Test

    What happens when it goes wrong?

    “It worked once” is not testing. We check the paths people will actually take, on the devices they use, including the paths nobody hopes they’ll take.

    Test sheetExample
    CheckExpectedFailure path Forms and bookingPassHandled Stage movementPassHandled DuplicatesPassHandled MobilePassHandled Error pathsPassHandled
    Gate: failure paths pass
  7. Phase 07

    Launch

    Is everything ready, including the people?

    Final checks, going live, and a handoff your team can use. You shouldn’t need us to explain the system every time someone asks how it works.

    System guide · excerptExample

    New inquiry workflow. Runs when someone submits the contact form.

    Automatic: record created, stage set, confirmation sent, owner notified.

    Your team: the owner calls, records the outcome and moves the stage.

    Don’t change: the stage names. Other workflows depend on them.

    Gate: handoff complete
  8. Phase 08

    Improve

    What’s worth changing next?

    Launch doesn’t mean finished. The business keeps moving, and the system should keep up. We don’t create retainers just to create retainers. Ongoing work should exist because ongoing value exists.

    After launch, things change
    • Services
    • Customers
    • Team responsibilities
    • CRM needs
    • The website
    • Automation timing
    Gate: worth doing, and scoped

Most delays aren’t technical. They happen when nobody is sure whose move it is.

Not every project uses every phase the same way. A focused fix may move through some quickly. The status stays visible either way.

Reviews

“Make it pop” is not a change request.

Gut reactions are welcome. We’ll help turn them into something we can build. Tap a comment to translate it.

How reviews work

  • One consolidated round, not scattered threads
  • One clear decision-maker
  • Comments on the review link or in written notes
  • Contradictions resolved before they reach us
  • Preferences kept separate from functional issues
  • Unresolved decisions surfaced, not buried

Feedback works better when it’s specific and in one place. That’s what keeps a review round from becoming three.

When something new comes up

Scope creep usually starts as “one quick thing.”

Projects change. That’s not automatically bad. The scope just shouldn’t change invisibly. Pick a mid-project request and follow it.

1

The request

2

Inside the agreed scope?

3

What happens

Schedule it.It joins the plan like any other task, and it goes in the log.

3

What it would affect

    4

    You decide, on record

    • Add itScope expands, with the impact agreed first.
    • Swap itSomething else comes out to make room.
    • Park itIt waits for a later phase, written down.

    A change is easier to manage when everyone agrees that it is a change.

    We don’t want to nickel-and-dime reasonable decisions. But untracked additions make bad projects. How pricing and scope work

    Ownership

    We build it. You hold the keys.

    Everything we set up is set up for your business, in accounts your business controls.

    Built and set up by us 0

    Nothing left on our side. That’s the point.

    Owned by your business 8

    DomainYours
    WebsiteYours
    CRM accountYours
    Customer dataYours
    Admin loginsYours
    Pipelines and workflowsYours
    IntegrationsYours
    DocumentationYours
    Your business shouldn’t be held hostage by your technology provider.

    You own your business and your data. We design, build, manage and improve the systems that support it.

    If we work together long term, it’s because the work is useful, not because leaving would be hard.

    Specific terms are governed by each project’s service agreement.
    Working together

    Meetings are for decisions, not for proving the project exists.

    We’d rather send a useful update than schedule a call to say there’s no update.

    Use a call forThings that need a conversation

    • Kickoff
    • Discovery
    • Decisions
    • Reviews
    • Complex problems

    Write it down forThings that need a record

    • Status
    • Next steps
    • Small approvals
    • Decisions made

    You’ll always knowWhere it stands

    • The current stage
    • The next decision
    • Who owns it
    • Known blockers
    • What’s in scope
    • Where feedback goes
    • What’s been tested
    • What launch requires

    Bring thisThe best projects have an engaged client, not an absent one.

    • Decisions
    • Context
    • Approvals
    • Access
    • Accurate information
    • Real feedback

    We can build the system. You still have to tell us what’s true about the business.

    We’ll push back onSometimes the useful answer is “we shouldn’t build that.”

    • Unnecessary complexity
    • Duplicate systems
    • Automating broken processes
    • Too many pipeline stages
    • Bloated websites
    • Pointless integrations
    • Custom work native features already solve

    We’ll say so, and explain why. More configuration is not automatically more value.

    The principle behind all of it

    Make the business easier to run.

    The technology should support the business, not become another business to manage.

    • WebsiteA good website makes the next step obvious.
    • CRMA good CRM makes the current state visible.
    • AutomationGood automation removes repetitive work.
    • The projectA good project makes it obvious whose move it is.
    Your move

    Tell us what isn’t working. We’ll figure out what needs to change.

    Start with the problem, how it works now, even if it’s messy, and what the business should do better.