Where opportunity finds opportunity

Done is a document, not an opinion.

We build SaaS products, custom software, integrations, automation and AI features — and every one of them starts as a written specification with numbered acceptance criteria, so “finished” is something you can read and test before a dollar of it is billed.

Start a project See how we work

Practice: Software engineering
Principal: Dalton Redden
Based: St. Louis, MO · US Central
Engagement: Fixed price, per milestone
Contact: One architect, no layers

SaaS products Custom software Integrations & middleware Automation & pipelines AI features Rescue & hardening

§ 01

The domain changes. The method doesn't.

Plenty of shops specialize in one vertical and hand you the same product twice. We specialize in how work gets defined, priced and verified — which is why the range of what we build is wide and the way it gets delivered never moves.

SaaS products

Multi-tenant applications from schema to invoice: accounts and roles, subscription and metered billing, admin tooling, audit trails, and the webhook plumbing nobody puts in the demo.

Custom software & internal tools

Line-of-business applications, operations dashboards, customer portals, and the unglamorous internal tooling that finally replaces the spreadsheet everyone is afraid to touch.

Integrations & middleware

Getting two systems to trust each other with money and data — payments, CRMs, logistics and dispatch platforms, ERPs. Signature verification, idempotency keys, retries, dead-letter queues, reconciliation jobs.

Automation & data pipelines

Event-driven workflows, scheduled jobs, two-way syncs with drift detection, and the dead-man alerting that tells you a feed went quiet before a customer does.

AI features that actually ship

Extraction, classification, retrieval and agentic workflows with schema-validated output, retries with model fallback, hard spend caps, a full prompt-and-response audit trail, and a human gate in front of anything irreversible.

Rescue & hardening

Inherited a codebase nobody wants to touch. We characterize the behavior with tests, stand up CI, document the failure modes — and only then start changing things.

Stack

TypeScript and Node across the board — Express, Fastify, Hono — with React on the front end, PostgreSQL and Redis, BullMQ for queues, Cloudflare Workers / D1 / R2 and AWS for infrastructure, Stripe and HubSpot for the commercial surfaces, REST and GraphQL between everything, Vitest and GitHub Actions gating the lot. If your project needs something outside that list, we'll tell you plainly instead of learning it on your budget.

§ 02

How the work runs, start to finish

Six steps, in this order, on every project regardless of size. Nothing here is a sales process — it is the delivery process, written down.

STEP 01

Scope conversation

Twenty to thirty minutes, no deck. What the system has to do, what it has to talk to, what “broken” would look like on a Tuesday afternoon, and what your real constraints are — deadline, budget shape, the vendor whose API you're stuck with.
STEP 02

A written specification, before a price

You get a short requirements document: data model, external interfaces, failure modes, out-of-scope list, and numbered acceptance criteria in plain language — AC-1.1: a replayed webhook never produces a second charge. If we're a fit for the project, that first spec is on us. It's yours either way, even if you take it somewhere else.
STEP 03

Fixed price, milestone by milestone

Milestones map to acceptance criteria, not to hours. No meter running while we read your vendor's documentation. You fund one milestone at a time through escrow and release it when its criteria are demonstrably met.
STEP 04

Decomposition into isolated packages

The build is split into packages that can be written and tested independently, each one pinned to a strict TypeScript interface contract. Contributors receive the interfaces and the acceptance criteria — not your company name, your customer data, or the rest of the system.
STEP 05

CI-gated delivery

Every change runs lint, typecheck, tests and a coverage floor before a human looks at it. Then the pull request is read against the acceptance criteria, one by one, by the architect who wrote them — and he makes the merge call. A pull request that misses a single criterion does not merge.
STEP 06

Handover and after

Repository, documentation, runbook, and a recorded walkthrough of the architecture. Infrastructure in your accounts, IP assigned to you, no proprietary runtime holding your code hostage. Then we stay reachable — integrations break in week three, not week one.

Why it's built this way

Most software arguments are definition arguments wearing a technical costume: the client thought “done” included the thing, the developer thought it didn't, and both are convinced they're right. Fixed price only works when done is written down first and neither side gets to quietly move it. Everything above is the machinery for making that stick.

§ 03

Proof, in the form of artifacts

No logo wall, no round numbers we can't source, no testimonials we wrote ourselves. The machinery instead — three artifacts from our own engineering standard, the same three your project would produce.

src/contract.d.ts Interface contract

// Package interface contract. DO NOT MODIFY.

export type VerificationFailureReason =
  | "MALFORMED_HEADER"
  | "NO_MATCHING_SIGNATURE"
  | "TIMESTAMP_OUT_OF_TOLERANCE";

export type VerificationResult =
  | { ok: true; timestamp: number }
  | { ok: false; reason: VerificationFailureReason };

/**
 * Pure function. Must never throw. Must use a
 * constant-time comparison for the signature check.
 */
export declare function verifyStripeSignature(
  input: WebhookVerificationInput
): VerificationResult;

Every package is defined by a type contract before any implementation exists. It fixes the boundary, makes the package independently testable, and means two pieces written a week apart still fit together.

acceptance-criteria.md Definition of done

AC-1.1A correctly signed request with a new event id returns 200 and the handler is invoked exactly once.
AC-1.2A body modified after signing returns 400, the handler is never invoked, and the comparison is constant-time.
AC-1.3A malformed or expired signature header is rejected without leaking which check failed, and the server never returns a 500 for any input.
AC-1.4Re-posting an already-processed event returns 200 { duplicate: true } and does not re-run the side effect.

Written in a language you can hold us to. Each one is a milestone gate, a test in the suite, and a line on the review checklist — the same sentence doing all three jobs.

.github/workflows/ci.yml The merge gate

name: ci
on: [pull_request]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck   # tsc --noEmit, strict: true
      - run: npm test            # vitest run --coverage

Reusable and identical across every repository we own, so no project gets a weaker standard than another. Red pipeline, no review. Missed acceptance criterion, no merge. Our own internal tooling is held to it too — the lead-intake service that runs this business is a Cloudflare Worker on D1, written in strict TypeScript and tested under the same rules.

§ 04

What you can hold us to

Commitments, not adjectives. Each of these is written into the engagement.

Fixed price, funded per milestone

You know the number before work starts. Money moves through escrow one milestone at a time, released when the criteria for it are met. Scope changes become new, separately priced milestones — never a surprise invoice.

Confidentiality by construction

Package briefs are sanitized: your identity, your customers and your commercial context are stripped before anyone sees a line of the spec. Everyone who touches the work has signed an NDA and IP assignment first. It's a structural boundary, not a policy promise.

One technical contact, US Central

You talk to the architect who wrote your spec and reviews every pull request — not an account manager relaying messages. Same-business-day replies, St. Louis hours, in writing so decisions stay findable.

You own all of it

Source, IP, infrastructure accounts and credentials, in your name, from day one. Standard stacks with no bespoke runtime and no license to keep paying. Handover includes the documentation needed to hire someone else.

Tests and CI are part of the deliverable

Not an upsell, not phase two. The test suite and the pipeline ship with the code, because they are the only durable evidence that the acceptance criteria were ever true.

An honest no, early

If the project is a poor fit, priced against reality it can't meet, or better solved by software you can buy for $40 a month, that's the first reply you'll get. Turning down bad-fit work is cheaper than delivering it.

§ 05

Who you're actually working with

Dalton Redden is the Principal Solutions Architect and the only person you deal with. He runs the scope conversation, writes the specification, splits the build into packages, reviews every pull request against the acceptance criteria, and makes every merge decision. Nothing reaches your repository without passing through him.

Behind that, Opportineer runs a vetted engineering bench: contract engineers who passed a CI-verified qualification task before their first assignment, work only on isolated packages against interface contracts, and sign NDA and IP assignment before they see a specification. That structure is what makes serious engineering capacity available on a fixed price — and why your business context never leaves the room.

The name is the whole thesis. Clients get real engineering without hiring a department; engineers get clear, funded, portfolio-worthy work without chasing clients. Two kinds of opportunity, pointed at each other.

Dalton Redden — Principal Solutions Architect Opportineer · St. Louis, Missouri · US Central (UTC−6/−5)

Contracting: Fixed price only
Funding: Milestone escrow
Minimum: One spec'd milestone
Response: Same business day
Meetings: Scope call, then async

Send the messy version. We'll write the clear one.

You don't need a requirements document to get in touch — producing that is the job. A paragraph about what you're trying to build, what it has to plug into, and when it has to work is enough to get a real answer back.

dalton@opportineer.com

What comes back

A reply the same business day, written by the architect — not a form response.
A concrete plan for your project, or a straight answer that we're not the right shop for it.
If it's a fit: a scope call, then a written spec with acceptance criteria and a fixed price against them.