Skip to content
Axel Rivera

How I Work

What Actually Happens

The same four stages whichever service you need. Here's what happens at each one, and what I'll need from you.

The Process

Four Stages, Every Time

  • 01

    Tell Me What's Breaking

    The more specific you are about what's breaking, the more useful my reply will be. A rough idea is enough to start. This is the first step whichever service you end up needing.

  • 02

    Scope and Cost

    I tell you what I'd do, including when the answer is nothing. Some jobs get quoted as one number for the whole build. Others are billed by the hour. Which one fits depends on how defined the work is when we start, and what it costs depends on what it has to do.

  • 03

    Build

    I split work into phases wherever a project allows it. You see progress as it lands, and changing direction or stopping costs less than it would halfway through one long build. Expect a written update once a week, most of the time, set differently at the start if a project needs it.

  • 04

    Handoff

    You get a walkthrough and written notes on how the thing runs. What else comes with it, source code included, depends on what we built, and ownership gets settled in writing before the build starts rather than after. For fourteen days after handoff, anything that doesn't work the way we agreed, I fix.

Standards

How I Handle Your Access and Your Data

Fifteen years of building software is mostly knowing which shortcuts cost you later. You shouldn't have to ask whether the person you hired is handling your business's data properly, so here's the standard, on every project.

  • I Ask for the Least Access That Does the Job

    I tell you what access I need and what it's for. If the work only has to read something, it doesn't get permission to change it.

  • Your Credentials Are Handled Like Credentials

    An API key goes where it belongs, not into a chat thread or a shared document. When the project ends, I don't keep access I no longer need.

  • Anything That Can't Be Undone Gets a Stop

    A confirmation step goes in before the thing that needs one. That's a decision made while the work is being designed, not a patch after the first accident.

  • Your Data Stays Where It Lives

    I don't copy your records somewhere else to make a build easier. If the work genuinely needs information to move, you'll know before it moves.

  • It Keeps Working After I'm Gone

    Nothing I hand over should depend on me being reachable. No clever trick that only I understand, and written notes on what runs where.

That's the standard on every project. The Follow Up Boss beta has its own limits written out in full on its own page.

What I Need

What Makes This Go Faster

  • For a Build

    • Concrete examples of what isn't working today
    • Access to the hosting and accounts the site already uses
    • One person who can say yes to a decision

  • For Work Against a Live System

    • An API key for the system being connected
    • A test account, if there is one. Not every system has one.
    • The person who owns that system, in the conversation

Questions

Things People Ask First

  • What if I'm Not Sure Which Service I Need?

    Tell me about it and I'll tell you what I'd do, including when the answer is nothing.

  • Who Owns the Work When It's Done?

    It depends on the project, and we settle it in writing before the build starts. Some of what I build is yours outright. Some of it is access to something I keep running and improving.

  • What Happens After Launch if Something Breaks?

    For fourteen days after handoff, anything that doesn't work the way we agreed, I fix. After that it's new work, and new work is a new conversation.

No Pitch and No Deck

The first conversation is about the problem. If there's a process in your business that eats a day a week, tell me about it.

Get in Touch