Services How we work

What working with one accountable engineer actually looks like.

No account manager, no bench, no discovery phase that ends in a slide deck. This page is the whole process: how an engagement is shaped, what the first two weeks contain, how work ships, and how it is handed back to you.

01

Three ways to engage

Every engagement is one of three shapes. Picking the shape first keeps the commercial conversation short and the technical one honest.

Fixed-scope build A system, a price, a date

Fits when
The problem is well understood and the output is a system you can describe in a page: an integration, a replacement for a specific legacy application, a product release.
You get
A written scope, milestones with acceptance criteria, working software at each milestone, and a handoff package at the end.
Pricing
A fixed quote after the audit, paid by milestone. Changes go through a short written change process, not a surprise invoice.
Length
Weeks to a few months. Anything longer is split into phases, each with its own scope.

Retained engineer Monthly hours, systems that keep evolving

Fits when
You run systems that change with the business: new regulations, new divisions, new reports. This is how our longest client relationship has run since 2016.
You get
A monthly allocation of hours, one engineer who knows your systems end to end, priorities set together each month, and no relearning cost when the next change comes.
Pricing
A monthly rate for the allocation. Unused hours are visible, not hidden. Scaling up or down takes a conversation, not a renegotiation.
Length
Open-ended, reviewed together. Ending it means a proper handoff, not a cliff.

Audit and rescue Two weeks inside an existing system

Fits when
Something is fragile, slow, or unknown: the engineer left, the vendor disappeared, the month-end job fails and nobody knows why.
You get
A written report: what the system actually does, where the risk is, what to fix first, and what each option costs. You can act on it with us or without us.
Pricing
A fixed fee for the two weeks. If we then do the work, the audit is the first milestone, not an extra.
Length
Two weeks, read-only access, no changes to production.

02

The first two weeks

Every engagement, whatever its shape, starts the same way: with the system as it actually is, not as the documentation says it is.

  1. Day 1
    A scoping call and read-only access

    Thirty minutes to hear the problem in your words. Then access to code, databases, and jobs, read-only, on your systems. Nothing is copied out.

  2. Days 2–5
    The audit

    We read the code, trace the data, list the scheduled jobs, and find out who depends on what. Questions go to the people who run the system today, in short written batches, not workshops.

  3. Days 6–9
    The architecture note

    A written document: what exists, what should change, in what order, and why. For a build, it becomes the scope. For a rescue, it is the deliverable.

  4. Day 10
    Your decision

    A quote or a monthly allocation, with milestones. You can say no here and keep the document. Either way, the plan is specific enough to act on.

03

The working rhythm

Working software every few weeks

Work ships in increments you can use, not in a reveal at the end. Each milestone has acceptance criteria written before the work starts, so "done" is not a negotiation.

Direct access to the engineer

You talk to the person writing the code. Questions get answered by someone who knows the answer. There is no layer whose job is to schedule the next meeting.

Decisions written down

Every architectural decision gets a short note: the options, the choice, the reason. Two years later, the note is why the next engineer does not undo it by accident.

Your repository, your infrastructure

Code lives in your source control from the first commit. Systems run on your infrastructure or a cloud account you own. If the engagement ended tomorrow, you would already have everything.

Onshore, under US jurisdiction

All work is done in Puerto Rico. No subcontractors, no offshore processing, no company data on third-party services. For regulated businesses this is often the first question, so it is answered here.

04

Handoff

Software should leave with documentation, tests, and no apologies. A handoff package contains:

  • A README that gets a new engineer from clone to running system in an afternoon.
  • Architecture notes and the decision log.
  • Automated tests for the behavior that matters, and a description of what is not covered.
  • Runbooks for the things that go wrong at 2 a.m.: the failed job, the stuck queue, the restore.
  • A recorded training session for your team, and a written list of every credential and where it lives, so they can be rotated the day we leave.

If you want us to stay available afterward, that is a retained engagement at a small allocation. If you do not, the package is designed so you never need to call.

05

What a statement of work contains

Procurement teams ask for this before the first call, so here it is. Every statement of work we sign has these sections, in this order.

  1. 01
    Scope. The system, in a page, with what it does and who uses it.
  2. 02
    Out of scope. Named explicitly. The things people assume are included that are not.
  3. 03
    Deliverables. Software, documents, and training, each described so both sides recognize it when it arrives.
  4. 04
    Milestones and acceptance. Dates, what is delivered at each, and the criteria that make it accepted.
  5. 05
    Access and security. Company data stays on company systems; confidentiality terms; who provides what access and when.
  6. 06
    Price and payment. Fixed quote or monthly allocation, payment on milestone or monthly, terms.
  7. 07
    Changes. How a change is requested, estimated, and approved in writing before it is built.
  8. 08
    Ownership. Work for hire. You own the code, the documents, and the accounts.
  9. 09
    After delivery. What support is included, for how long, and what a retained arrangement would look like.

06

When we say no

A one-engineer firm is a good fit for a specific kind of work, and a bad fit for others. We say so on the first call rather than three months in.

  • Staff augmentation. If you need six developers on your team by Monday, that is an agency's job.
  • 24/7 operations. We build systems that run without babysitting, and we document how to restore them. We do not staff an on-call rotation.
  • Brand and marketing design. We design software interfaces well. Logos, campaigns, and brand systems belong with a design studio.
  • Work that has to leave Puerto Rico. If your policy requires processing in a specific other location, we are not the right partner.

Start with the thirty-minute call.

Tell us what is broken or what is next. You will hear back within one business day, from Gabriel, not a sales team. Se habla español.

Case study · 01

Ten years with a health insurer How the retained model works in practice: five systems, one engineer, no relearning cost. Read the case study →