Project Type: Product architecture and full-stack build (client engagement)
Product: DecideNorth, a marriage-readiness assessment for couples (decidenorth.com)
Role: Sole builder. Product, architecture, and code.
Duration: April 2026 to present (ongoing)
Context
DecideNorth is a marriage-readiness assessment for couples who are seriously considering getting engaged. Each partner answers 74 questions privately, on their own, and the product shows them where they align, where they do not, and which conversation is worth having next. It is live at decidenorth.com.
The category it sits in is full of products that will happily tell you whether your relationship is going to work. That is the one thing this product refuses to do, and nearly every engineering decision below follows from the refusal.
Live at decidenorth.com. The promise is a shared map and deliberately never a verdict.
Problem
A relationship product is a place where a confident wrong answer does real damage. Somebody reads it at two in the morning and it changes what they do next. There is no version of this where an output nobody can explain is acceptable.
The obvious 2026 build is to hand both partners’ answers to a language model and ask it for insight. It is fast, it demos beautifully, and it produces something nobody can audit, reproduce, or defend when a customer asks why it said that.
The most persuasive statistic in the entire category does not survive contact with the literature. Competitors quote a divorce-prediction accuracy of 93.6%. Heyman and Slep cross-validated that model in 2001 and out-of-sample accuracy fell to roughly 21%.
It also has to be a real commercial product: a partner-invite loop people actually finish, a paywall, a generated keepsake, and a claims posture that survives an FTC reading.
Process
1. Draw the AI boundary before building anything
The first architectural decision was a line rather than a feature. Everything that shapes what a couple is told about their relationship would be deterministic code. A language model would be allowed on exactly one surface: the 90-second audio note that invites the second partner.
That surface was chosen because it is the one place where a model adds something real, which is warmth and a reason to press play, and where being wrong is recoverable. An awkward sentence in an invitation costs a little charm. A hallucinated insight about somebody’s marriage costs considerably more.
Fourteen modules ended up on the deterministic side of the line. One on the other. Two independent kill switches on that one.
The first architectural decision: fourteen deterministic modules, one surface where a model runs.
2. Make the scoring a pure function
74 questions across 8 dimensions. Every answer is scored as its distance from the healthiest response on that item’s own scale, weighted, and summed into its dimension. Questions that legitimately inform two dimensions carry an explicit split weight instead of being counted twice.
Same answers in, same result out, every time, with the arithmetic in view. Where a dimension has too little signal it returns insufficient data instead of a confident wrong band. Three or more most-negative answers inside one dimension raise a distress flag that changes the copy the couple sees.
74 questions, one at a time, each carrying its own reason for being asked.
Distance from the healthiest answer, weighted into eight dimensions, with no model in the path.
3. Build the blind-spot engine out of four rules
The interesting product claim is not that the tool finds disagreements, because both partners can already see those. It is that it finds the patterns neither of them can see alone: apparent agreement with divergent behavior underneath it, a strength that turns out to rest on avoidance, one partner treating a subject as closed while the other treats it as open.
Four deterministic rules over the joint answer matrix. Every firing has to point at two specific question IDs or it does not get to speak. One blind spot per dimension, three per couple, and finding nothing at all is a valid result the copy handles gracefully. That last constraint is what separates a detector from a horoscope.
Four rules. One that cannot cite two specific answers does not get to speak.
4. Treat the model’s output as untrusted input
The one AI surface gets a validation gate. Nine checks: word count inside the 90-second budget, no em dash, none of 16 banned words, none of 15 banned phrases, no markdown, no stage directions, the listener’s first name at least twice, and both the named strength and the named gap actually present in the text.
Most of that list exists because of what those words would do to a person. A partner who hears the phrase red flag before they have answered a single question has been failed by the product, whatever the model intended by it. Privacy promises and social proof are load-bearing claims, so they belong in copy a human wrote and can be held to.
A draft that fails any check gets one retry with the specific failures quoted back to the model. Fail twice and the job dies.
The single surface a model touches: a 90-second note that invites the second partner.
Nine checks before anyone hears it. The banned words are the product’s promise, enforced.
5. Then leave the model switched off, because it could not pass
Wiring the script generator to the live scoring engine would have fed raw dimension slugs into the prompt as though they were English. The gate would have caught most of it. Some of it would have reached a real person’s ears as the word financial_alignment.
So that branch throws. Today’s audio speaks a script a human wrote, synthesized by Gemini’s text-to-speech, and the generator waits for a resolver that does not exist yet. The second switch is independent of the first: a daily spend cap enforced atomically inside Postgres rather than in application code where a race could slip past it, with an operator alert that carries the day and the reason and no user data whatsoever.
The gate was built to hold the model to a standard. It is currently holding.
The generator throws rather than shipping raw slugs into somebody’s ears. It is still off.
6. Put the claim standard in the build
A shell script in CI fails the build if 93.6%, a 94% or 96% accuracy claim, or any predicts-divorce phrasing reaches user-facing code. Research notes and planning docs are allowlisted, because they legitimately discuss the critique.
A rule that lives in a style guide loses eventually. The pressure to use that number arrives every time somebody writes a landing page and it is always the strongest line available. A rule that fails the build wins that argument every time, including the times nobody is watching.
Three more guards sit beside it: design-system isolation between the app and the PDF, no floating dependency versions, and no development auth keys in a production build.
The claim posture, front of house: patterns and language, and no prediction.
The same posture as a build step. The category’s favourite statistic fails CI.
Solution and Outcome
Live at decidenorth.com. 354 commits since 11 April 2026, 40 Postgres migrations, 282 test files, 17 end-to-end specs.
Zero model calls in scoring. Zero in the report. One surface where a model runs at all, carrying two independent switches.
A blind-spot engine that is four auditable rules with an evidence burden rather than a prompt.
The full paid path built: partner invite, pre-paywall reveal, Stripe checkout that reconciles the amount instead of silently accepting it, and a generated PDF Alignment Book from a deterministic content projector.
Row-level security throughout Postgres with an adversarial test suite against it, and analytics that carry no answer content.
The category’s most quotable statistic cannot enter the codebase, enforced in CI.
The trade is worth naming plainly: this took longer than prompting a model would have. What it buys is a product where every claim about somebody’s relationship traces back to their own answers and the arithmetic that ran on them.
What all of the determinism is protecting. Aligned, worth exploring, and never a verdict.
Most AI products fail at the boundary rather than the model. Nobody decided in advance which decisions the model was allowed to make, and that is cheap to settle on day one and expensive to retrofit.
Thanks for reading this far. If this is the kind of work you need, I would like to hear what you are building.
A live couples readiness product where every judgment about the relationship is deterministic code, and a language model is allowed on exactly one surface.