Service one

Task Board Bays

A task board bay is the first structure the company opens on any engagement. It is a named working surface, physically pinned on the porch and mirrored electronically, where every request, defect and open question is sorted into lanes with an owner. The bay is groomed with the client team at the start of each week, so the board reflects reality rather than a plan written months earlier.

Bays are deliberately small. A single bay holds one product area or one integration boundary, which keeps the number of cards visible and the conversations sharp. Each card carries a title, a one line intent, an owner and a link to the build sheet or release note it will eventually produce. When work leaves the board it leaves with a record of what changed, so the bay doubles as a delivery history.

Service two

Build Sheet Runs

A build sheet run records the exact conditions of a build: the source revision, the dependency versions, the configuration used, the environment and the person who triggered it. The sheet is written as a durable document beside the artifact, which means any later run can be compared against it or repeated from it. Builds that fail the sheet are treated as defects, not accidents.

The porch team runs build sheets for applications, scheduled jobs and integration services alike. Where a client has automated pipelines, the sheet is generated automatically and reviewed for completeness; where a client still compiles by hand, the run becomes the first step toward repeatability. Either way the outcome is the same, a build that can be explained months after it shipped.

Service three

Release Note Desks

The release note desk converts merged work into language that operators, clients and support staff can act on. Notes are drafted beside the build sheet, in plain sentences, and they name what changed, what a user will notice and what to check if something misbehaves. The desk writes for the person who will be on call, not for the person who wrote the commit.

Each note is reviewed before publication and linked to its task cards. On the porch the desk is a flat working surface with ruled paper, and the discipline is simple: if a change cannot be described in a short paragraph, it is not ready to ship. Release notes remain on file with the release artifacts so the history stays readable long after the team has moved on.

Service four

Code Review Windows

Review windows are short, scheduled and protected. A reviewer reads the change alongside its task card and build sheet, checks the logic and the integration boundary it touches, and leaves a decision rather than a list of open suggestions. The window closes at a fixed time, which keeps review latency predictable and keeps reviewers from becoming a permanent bottleneck.

Windows are held for every change that reaches a shared branch, including small ones, because the habit matters more than the size of the change. When a window finds a genuine problem the reviewer records it as a new task card rather than extending the window indefinitely. That rule keeps the board honest and keeps the merge queue moving.

Service five

Refactor Review Rounds

Refactor rounds are scheduled separately from feature work and look only at the shape of the codebase. Each round produces a written risk ledger and a small, ordered plan: which structures are fragile, which interfaces are leaking policy, and which changes would reduce future cost without touching behaviour. Nothing in a refactor round ships until the plan has been reviewed with the client.

The rounds exist because structural work that arrives as a surprise rewrite usually fails. By treating it as a governed activity with its own ledger, the porch team keeps refactoring small, testable and reversible. Each round ends with a short note describing what was assessed and what was deliberately left alone, so the decision trail survives staff changes.

Service six

Handoff Sittings

A handoff sitting is a single, structured meeting in which the receiving team is walked through the task board, the build sheets, the release notes and the open risks. Nothing is transferred by email alone. The sitting follows a written agenda and ends with a signed note that names what the receiving team now owns and where the unresolved questions live.

The company treats the sitting as part of delivery rather than an afterthought. If the receiving team cannot explain how to build and release the system unaided, the engagement is not finished. Handoff notes are kept with the board, so a later team can repeat the exercise without starting over.