Selected work
Work where the hidden state mattered.
This is the kind of work I want to be known for: vague business workflows turned into explicit backend
models, smaller product surfaces with clearer rules, and systems that make hidden state easier to reason
about. These examples started as practical product or operational needs that had to become real systems.
PaidToday Kit helps a small service business prepare professional follow-up material when a client
relationship has become uncomfortable.
The useful part of the project is the product shape: a short intake, a clear checkout boundary, and a
generated result tied to a real purchase state.
The product constraint
I wanted the first version to stay small. A buyer should be able to answer a few questions and get a useful
result. No dashboard. No onboarding maze. No large product surface before the core workflow has proven itself.
That simple choice still creates real backend requirements: the app needs a durable record of the order,
the right to receive the result, generation state, and delivery state.
The flow
Landing page
Intake form
Draft record
Checkout
Server verification
Generated result
Copy / Markdown
The browser should not be trusted to decide that a paid result is unlocked. The server verifies the order
state before showing or generating the output.
Decisions I cared about
Order state is separate from output state
Keeping those facts apart makes the workflow easier to reason about and support.
Access is explicit
The right to receive a result deserves a real model, not a pile of one-off conditionals.
The paid path is the product
The important design work is the intake, checkout, entitlement, and result-delivery path.
Scope is part of the architecture
The first job is proving that the small workflow is useful before turning it into a platform.
At Checkr, I was the sole engineer responsible for turning an internal invoice-generation script into a
production backend workflow for usage-based billing.
The value was not just automation. The project turned implicit billing logic into software that could run
on a regular cadence, deploy through normal engineering practice, and give Finance and Accounting a more
inspectable view of invoice state before final invoicing.
The starting point
The original process lived closer to an operational script than a durable product system. It encoded real
business logic around service usage, tenant configuration, SKU definitions, pricing rules, and billing
periods, but it needed to become something safer: repeatable, deployable, and understandable when people
had questions about the numbers.
That is the kind of messy middle I like: the business already knows the workflow matters, but the software
model is not clean yet. The job is to preserve the truth of the workflow while giving it a better technical
shape.
The workflow I productized
Service usage
Tenant context
SKU logic
Pricing rules
Billing period
Invoice-like state
Finance visibility
I owned the backend implementation, CI/CD setup, deployment path, and production rollout. I also aligned
with Accounting and Finance on the operational behavior of the system, including moving invoice-state
generation toward a recurring cadence during the billing period instead of leaving visibility until the
end-of-month picture.
Decisions I cared about
Turn the script into a product surface
A useful internal workflow deserves production behavior: deployment, repeatability, ownership, and a
shape future maintainers can reason about.
Make billing logic explicit
Usage, pricing, SKUs, and billing periods should not be hidden in an ad hoc execution path. The system
needs to expose what it believes and why.
Design for safe re-runs
Billing workflows need deterministic and idempotent behavior. Running the workflow again should not
accidentally invent new revenue or double-count usage.
Give Finance an earlier picture
The system was valuable because it moved visibility forward: less waiting for final invoicing, more
ability to see what invoice state was forming.
The value
This project is representative of the backend work I do best: taking a fragile or ad hoc business workflow,
understanding the rules behind it, and turning it into reliable production software that helps the business
operate with more confidence.
The important engineering concerns were not flashy. They were the concerns that matter in revenue systems:
deterministic output, idempotent execution, traceable results, operational debuggability, and a clean enough
model for the next person to maintain.
The initial request sounded small: help the agent team track customer referrals. On the surface, that can
look like a form, a link, and a few database fields.
The real work was more interesting. A referred shopper was not just a new lead. They entered an existing
home-shopping lifecycle with identity, authentication, state transitions, and internal follow-up attached.
The hidden complexity
Historically, a new shopper registered directly through the homepage using their own email address. That
gave the system a relatively clean assumption: if a shopper account existed, the person had initiated
signup and controlled the inbox associated with that identity.
Customer referrals changed that assumption. An agent or internal workflow could introduce an email address
before the referred customer had ever signed in. The system might know about an email, but the person had
not yet authenticated or proven control of that inbox.
That distinction mattered because the shopper journey used strict lifecycle state. A shopper could not
simply appear anywhere in the journey. The system needed to know who the person was, what state they were
in, and which transitions were valid.
The real system boundary
Agent referral
Email identity
Invitation
Magic link
Authentication
Shopper lifecycle
Internal follow-up
The important question was not only whether the product could send an invitation. It was what that
invitation meant. Was this a new shopper, an existing shopper, a pending identity, or an authenticated user
returning through a different path? Each answer implied different lifecycle behavior.
Magic links made the experience low-friction, but they also made the workflow more stateful. A link was not
just an authentication mechanism. It was a product entry point that needed to identify the user, preserve
account integrity, and route the person into the correct state of the journey.
My role
I owned implementation of the referral flow while coordinating with product, UX, principal engineers, and
the broader product engineering team.
- Mapped how referrals entered the shopper lifecycle.
- Reasoned through pre-authenticated versus authenticated identity.
- Worked through magic-link entry behavior and post-authentication routing.
- Contributed backend and frontend changes for the customer-facing flow.
- Clarified edge cases around existing shoppers, new shoppers, and referral-created records.
- Documented previously implicit authentication behavior.
- Hosted knowledge-sharing sessions so the team could reason about the auth and lifecycle implications.
Although my strongest area is backend systems, this project required working across the stack. That was
useful. The frontend made the backend rules visible: where the user landed, what state they appeared to be
in, and whether the product experience matched the system assumptions underneath it.
The product-systems judgment
Referral flows, invitation flows, onboarding flows, and authentication flows often look simple from the
outside. They tend to sit at the exact point where product experience, identity, security, and lifecycle
state collide.
Identity is more than an email address
A referred email may exist before the person has authenticated or proven control of the inbox.
Entry points carry meaning
A homepage signup, agent referral, SSO path, and magic-link return are not always equivalent.
State machines need invariants
Every new entry path into a strict lifecycle model needs clear rules for valid states and transitions.
Invitations are side effects
Sending an invitation changes what can happen next. I would model it as a mutation, not a read path.
What this says about my work
This project is a good example of the work I am strongest at: taking a vague business request, finding the
real system boundaries underneath it, and making the rules explicit enough for the product to become more
reliable and maintainable.
The feature may start as "track referrals." The real value is making the workflow coherent.