Coast Competitions
A competition product designed as one accountable lifecycle, from an operator scheduling a prize to a customer inspecting the completed result.
- Design lead
- Cameron Calder · customer and operator journeys
- Engineering lead
- Joel Parfitt · product, payments and draw mechanics
- Operating model
- Founder-controlled launches through a private CMS
- Evidence
- Live customer and result states, captured July 2026
The work starts before checkout and ends after the draw
A prize competition moves through several sensitive states. An operator defines the prize, price, schedule, entry limit and skill question. A customer answers, selects available tickets and pays. The competition later closes, eligible entries are fixed, a winner is selected and a public result is recorded. If those steps are modelled as unrelated screens, inventory, payment and draw state can contradict one another.
Cameron mapped the end-to-end product, designed the customer and operator journeys, and made the changing state legible in the interface. Joel translated that system into a Next.js product deployed on Render, including the private operator surface, DNA Payments integration, ticket-state handling, draw mechanics and public results. The founder retained control of competition rules, commercial content, schedules and operational approvals.
The first release concentrated on the states that determine whether a customer can enter and whether an operator can complete the lifecycle cleanly. It did not treat every plausible growth feature as launch scope. That discipline gave the core transaction, operator controls and result record room to be explicit.
From a scheduled prize to an inspectable public record
2026 · Definition
Turn operating rules into product states
Mapped competition setup, entry eligibility, inventory, payment, close, draw and result as one stateful service rather than a set of pages.
2026 · Build
Separate customer, operator and payment responsibilities
Built focused public and CMS journeys, then connected DNA Payments without allowing payment authorisation to stand in for draw eligibility.
2026 · Launch
Release the public core loop
Launched live competitions, customer entry, payment and public results on the same product foundation. Operator controls remain classified separately as implemented.
14 July 2026
Capture the evidence state
Recorded the live storefront, competition detail and results archive. Repository and production-commit confirmation remain client-private and pending publication.
The customer product and the operating system behind it
Capability status definitions
- LiveAvailable in a public or deployed product.
- ImplementedBuilt, but release or approval is not evidenced.
- DemonstrationA labelled example using simulated data.
- ExploratoryResearch, specification or prototype only.
Competition storefront
Public discovery for active competitions, prior winners and routes into entry.
- Active competition catalogue
- Prize, price and close-time hierarchy
- Ticket availability context
- Winner and trust evidence
RepositoryClient-private Coast deployment repository
Entry and inventory
The transactional path connects the skill answer to currently available tickets.
- Skill question
- Ticket selection
- Inventory state
- Terms and competition context
RepositoryCoast product application
DNA Payments checkout
An external payment boundary handles card and supported wallet authorisation.
- Card checkout
- Apple Pay and Google Pay routes
- Authorisation outcome
- Return to product state
RepositoryDNA Payments integration
Operator CMS
A private workspace gives the founder control without requiring a developer release.
- Prize and schedule management
- Price and inventory control
- Competition-state changes
- Winner and result publication
RepositoryPrivate operator surface
Draw and result record
Completed competitions expose a reviewable record after the transaction has ended.
- Eligible-entry count
- Recorded seed
- Winning ticket
- Masked winner details
RepositoryCoast product application
Every handoff preserves the state the next actor needs
From publication to review
- PublishSet the prize, schedule, price, inventory and closing state.
- QualifyAnswer the skill question and choose available tickets.
- PayAuthorise card or wallet checkout through DNA Payments.
- RecordClose the competition, complete the draw and publish its result.
Payment authorisation and a completed draw are distinct product states. This flow describes implementation, not a legal determination of eligibility or fairness.
Inspect live product (opens in a new tab)The product before, during and after entry
Live competition detail and results make both sides of the public lifecycle inspectable. Private CMS evidence is described separately and is not represented by a fabricated interface.
Five decisions that protect the core lifecycle
Model the lifecycle explicitly
- Decision
- Represent publish, open, paid, closed, drawn and recorded states rather than inferring them from page availability.
- Why
- Customers and operators need the product to behave consistently as a competition changes over time.
- Consequence
- Inventory, calls to action and result publication can respond to a known state instead of ad hoc content switches.
- Tradeoff
- State transitions require tighter validation and more exception handling than a simple content site.
Keep payment separate from draw state
- Decision
- Treat DNA Payments authorisation as one boundary and competition eligibility or draw completion as another.
- Why
- A successful card event does not by itself define the final eligible set or prove that a draw completed.
- Consequence
- Reconciliation and error recovery can be reasoned about without rewriting the result record.
- Tradeoff
- The product must preserve and resolve more intermediate states when a callback or operation fails.
Publish an inspectable result record
- Decision
- Retain the competition, eligible count, recorded seed, winning ticket and masked winner after completion.
- Why
- A result should remain inspectable after the promotional page and checkout are no longer active.
- Consequence
- Customers and operators can refer back to the same public account of the completed draw.
- Tradeoff
- Public detail must balance inspectability with winner privacy and careful claims about what the record proves.
Put launches in the operator's hands
- Decision
- Use a CMS for prize, schedule, price, inventory and result control instead of hard-coded releases.
- Why
- The operator owns commercial timing and needs to react without waiting for engineering availability.
- Consequence
- Routine competition work becomes an operating task rather than a deployment task.
- Tradeoff
- Permissions, validation and recovery matter more because operational changes reach the live product directly.
Protect first-release focus
- Decision
- Prioritise the complete entry-to-result loop over speculative growth and engagement features.
- Why
- Missing lifecycle states would create more risk than a smaller set of well-connected capabilities.
- Consequence
- The launch shipped a coherent service that can be extended from real operating needs.
- Tradeoff
- Some acquisition and retention ideas remained outside the initial release.
Clear ownership at every system boundary
Live surface in a client-private repository
Coast public product
LiveDelivers the public storefront, competition detail, entry flow and public results.
- Next.js
- TypeScript
- Render
Live deployment is inspectable. Canonical repository URL and production commit are withheld pending client approval.
Implemented surface in the same client-private repository
Coast operator CMS
ImplementedProvides private competition, inventory, schedule, price, winner and publication controls for the operator.
- Next.js
- TypeScript
- Private operator access
Implementation is documented, but authenticated operator evidence and publication approval remain pending.
External payment boundary
DNA Payments
LiveAuthorises card and supported wallet checkout, then returns a payment outcome for the product to reconcile.
- Cards
- Apple Pay
- Google Pay
The integration is part of the live checkout. This case does not publish transaction volume or processor performance.
Product evidence surface
Public draw record
LivePersists selected draw details and masked winner information for customer review after completion.
- Result archive
- Public route
The live results page was inspected on 14 July 2026. Its presence is not an independent fairness audit.
A launch that includes the operating reality
Coast launched as more than a customer-facing campaign. The founder can control competitions, the customer can move through qualification and payment, and a completed draw leaves a public record. Designing those states together reduces the room for inventory, checkout, operator action and result presentation to tell different stories.
The next publication milestone is to reconcile the live release with its canonical private commit and add approved operational measures. Until that evidence is available, the case claims the complete shipped lifecycle and no more.
Building a product with hard rules?
Turn transactions and operator responsibilities into a clear, accountable product build.
Discuss a project