--- title: "The Bare Domain Returned a 404 Through the Mail Host" canonical: https://dxdev.com/blog/venture-from-idea-to-domain-in-two-weeks/ datePublished: 2026-07-23 --- At 4:55 p.m. on July 21, a user could enter an invite code, write a decision into a Postgres-backed log, reload the page, and see the record still there. Forty-eight hours earlier, we were still turning a loose venture plan into something we could actually use. We had a shared file home, a contribution-ledger prototype, a private repository, and a running conversation. We had no operating surface. Decisions were still trapped in prose, and next actions still depended on somebody remembering what had been said. ## The shared drive stayed, and the checklist went The first option we dropped was making the shared drive the center of the business. We kept it for working documents, deep dives, and the plan. It lost as the daily operating surface because a folder does not answer the immediate question: what is the one thing each person should do next, and what decision made that action real? The second was a conventional ordered checklist. The first version made sense on paper: set up this, then that, then the next thing. In review it was wrong for the actual state of a new venture. Two people do not begin from the same place, and a forced sequence made the workspace feel like a compliance form before it had earned any trust. We rebuilt it as a guide-first workspace. The checklist became **nine areas of concern**, each with a placeholder state, and the page chose a readiness-aware next step instead of insisting on a universal order. A user could shape the business from the current state rather than pretend every business starts with the same missing pieces. ## The part that had to be real Once we made that call, a static site was no longer enough. The Decision Log needed to be a real read and write surface, and a card linking back to a document would not do. We put the durable state in Neon Postgres and exposed it through Cloudflare Pages Functions. The application was deployed on the venture's own domain. Users authenticated with an invite code. The production secrets were wired into the deployment. The core acceptance test was deliberately boring: ```text sign in -> add a decision or task -> reload -> record persists ``` That test mattered more than a polished demo. It crossed the access boundary, the write path, the production database, and the rendered state a user would actually see. We ran it on the live site before calling the feature shipped. The alternative was to keep decisions in a shared document and build a prettier front end around it. That would have been faster for a screenshot and worse for the work. We needed structured decisions and tasks that the product could query. We also needed a small, explicit boundary. Invite-code sign-in was enough for the two-person v1. It was not the final identity system, and we filed the sign-in rate-limit follow-up instead of pretending the initial boundary was complete. We made a similar choice around project tracking. We tried a heavier ticket system, then used a repository-native issue board with epic labels. The work was already in the repository, the deployment was already tied to it, and the two of us needed less ceremony and no extra system to keep synchronized. The AI-run build removed the translation tax. We moved from the live business conversation to the page, database, deploy, and verification loop while the details were still fresh. It did not let us skip the decisions. The business partner still had to choose the working name, react to the contribution-ledger changes, and take the first dogfood pass. We still had to decide that the shared drive remained the file home, that the Decision Log became the operating record, and that the first production user experience should be narrow enough to verify. ## The deploy broke somewhere else The first production failure was in the landing page, and Postgres and the Functions API were fine. After a visual redesign, iOS Safari showed a white page with dead links and horizontal scrolling. The desktop site looked shipped. The phone session did not. The diagnostic path was short because the symptom was concrete. We reproduced it on an iPhone, isolated the heavy visual effects as the cause of the crash, fixed the visual failure and the horizontal overflow, then verified the repaired page on the device and on the live `www` route. The browser check caught a second problem. The subdomain worked while the bare domain still returned a 404 through the mail host. That was a broken launch path even though it was no product bug. We had [moved the DNS for the apex](/blog/status-redundancy-off-shared-infra/) and `www` records into the venture's deployment zone while keeping mail intact. The remaining redirect issue became a tracked follow-up. An agent can cover implementation ground quickly. A desktop screenshot that looks good does not make a broken phone session a success. Live behavior is still the constraint. ## Making the log drive tomorrow Two days later, we extended the Decision Log into a personalized status home. A signed-in user sees one ranked next action from the live log and a connection map that explains how the pieces fit together. That was the useful abstraction, and a dashboard full of equal-weight cards would have missed it. The home screen reduces too many possible moves to one defensible next action and shows the decision trail underneath it. We also shipped scheduled chat summaries. Daily, weekly, and monthly review cards post automatically, but only for complete days and complete review periods. We backfilled the daily channel through July 22 and the weekly channel for two complete weeks, then organized the shared server around Strategy, Updates, and Reviews. The automation sits downstream of the operating record. The summaries are a delivery mechanism for what the partnership has already decided and recorded, and they never become a second task system. That sequencing is the architecture. The database is the state. The workspace is the place where we change it. The guided home turns state into a next action. The scheduled chat cards make the state visible without requiring either person to remember a ritual. ## What the two days left open By the end of the second day, we had the live domain, the guide-first workspace, the database-backed Decision Log, the repository-native task board, and a handoff path. Pricing, trust, CTA routing, rate limiting, and the full identity model remained explicit tracked work. AI compressed the path from a concrete need to a working system. It did not turn uncertain business questions into settled ones. It did not choose the business model, validate the offer, or replace the business partner's judgment. It did give us a shorter loop between the decision and the proof. We could make a narrow choice, build the smallest surface that made the choice operational, run the real flow on the real domain, and leave the unresolved parts visible instead of burying them under a launch story. ## The check I would run on any new system It becomes real when the people responsible for it can return tomorrow, see the next decision, make it, and trust that the record will still be there. So test it that way: sign in, write a record, reload, confirm it persists, and run the check on the live site and on a phone.