Business

The problem

Jobs, phased payments and expenses lived in a spreadsheet. Receipts, client payments and new leads arrived by email. Estimates, contracts and change orders were written by hand, and nobody could say what a job had cost in labor until it was over.

The constraints shaped everything. The owner is not a programmer, client data had to stay on his computer, and nothing could reach the books or a client without his say.

Since the first version

• Never lost. A five-stage tracker on every job, a glowing next step, and a Next task button.
• One-click Send. The estimate goes to the client as a PDF from the owner's own Gmail, only when he presses Send.
• Every attachment read. Each PDF or photo in an email becomes its own item to review.
• A downloadable Mac app, built and released automatically when the version changes.

In review now: a pricing check before an estimate goes out, a rough range and site-visit questions from a lead's photos, Google review requests, a weekly scorecard of leads and wins, and instant follow-up for website leads.

Decisions behind it

• The model drafts, code decides. Prices, totals, dates, IDs and job matching are computed in code. If a model's draft drops a required fact, the app falls back to a plain template.
• Fewer fields. A sentence like "Home Depot 109.91 studs for Smith" fills in an expense. Every page keeps a by-hand form for when the model is off.
• Nothing sent for him. Emails open in his mail app to read and send. Reminders never mention fees or lawyers.
• Readable by design. The redesign cut 14 tabs to 5 groups, set text at 18px with nothing under 15px, and made every control at least 48px tall.

Where it goes next

A productizing plan finds about 70% of the app is generic, with the owner-specific parts being configuration rather than architecture. The plan is to treat this business as customer number one, then offer done-for-you setups to three to five local remodelers, with a pilot kit and sales sheet ready.

Two versions, on purpose

• A full web app. About 6,300 lines across 24 files, with a database, six roles and backups with checksums. Roughly half was inherited from the ChatGPT and Codex first draft; the lifecycle system, query layer, all six screens and the design system are the Claude Code rewrite. It runs on the owner's computer.
• A shareable version on Claude's artifact pages. Built to be shared with a link. It stores data in the page's shared store and falls back to the phone's own storage if sharing is not available.

What testing caught

• A migration that would have hidden every job. The generated database migration filled a status column with the literal text of its own name, so no job matched "active" and all of them vanished from every screen. It was reproduced against a rebuilt copy of the live database and patched by hand.
• No mobile viewport tag. The artifact laid out at desktop width and shrank to unreadable on a real phone. It looked fine on a laptop.
• Two people logging at once. Each person writes only their own document per job, so two crew members cannot overwrite each other. A second phone's entry updated the first live in testing.

How it goes live

• One source. The site's only source is a folder in the app's repo. Nothing gets dragged, dropped or uploaded by hand.
• Previews on every change. A GitHub Action builds and checks each pull request and posts a preview link, so the owner can see a change before it's live.
• Merge to publish. On merge, the Action uploads the build to Cloudflare Pages and then checks that the live domain is serving it.
• Public means public. Draft notes and placeholders stay out of the live pages. Open questions are kept in the project's notes instead.

Built for the owner to change

The site folder has its own guide for the next AI session on the owner's computer: explain changes in plain words, edit on a branch, run the build, share the preview, and never publish any other way. That lets the owner ask for a change in a sentence without learning Git.

Rules that keep it cheap and safe

• Preview before render. Every new ad starts as an HTML preview or storyboard. Nothing is rendered until it is approved, which saves hours of wasted renders.
• Modular end cards. Business name, phone, web address and tagline live in one brand file. The end card is its own segment, rendered separately and joined to the body, so a contact change re-renders only the card.
• Real sound, never synthesized. Effects are free-licence recordings, mixed to one loudness so music fits on top.
• Honest copy. No prices, no claims of jobs the business hasn't done, and no phone number in captions, where scrapers collect them.

One place to review them

Every ad set, in every style, sits in one private library page with its status: preview, rendered, scheduled or posted. That's where new sets are reviewed and pick what goes out next.

Decisions behind it

• Buffer, not TikTok's own API. TikTok only lets unaudited apps post privately, so a free Buffer plan does the public posting instead. Its free tier caps the queue at ten posts, which is why the weekly refill exists.
• A repo as the video host. Buffer copies a video only when it posts, so the file has to stay up until then. A public repo is free, simple to push to from anywhere, and keeps the videos off the business's own website.
• Launch, then a steady pace. The clay ads launched with a three-a-day burst over three days, then settled at about five a week.

What stays human

Following, commenting and replying are done by hand. TikTok quietly undoes automated follows, and real replies from the business matter more than volume. Profile changes behind TikTok's bot check also need a person to press Save.

The problem

AI labs and data brokers pay referral fees for introductions to established businesses that hold years of operating records. A business listing is only the start: someone still has to establish which records exist, who controls them, whether a buyer wants them, whether the owner wants an introduction, and how referral credit is recorded. Treating a company score as a qualified deal hides the work that matters. Fieldwork aims to deliver a small queue of opportunities, each with its sources and an explicit list of what still blocks an introduction.

What it does today

• Research: a background job queue reads each company's public pages and records every claim with its source and a confidence label. A discovery queue proposes new businesses from public directories for review, flagging likely duplicates.
• Buyer requirements: each buyer program's criteria and the referral agreement are recorded separately, with review dates, so expired terms stop counting.
• Prospect briefs: what is known, what still needs proof, likely record categories, and a fit hypothesis for each buyer naming the missing facts.
• Outreach preparation: drafts for sourced contacts, approved by a person before any campaign can send.
• Owner intake, deals and commissions: a single-use owner questionnaire with buyer-specific consent, a deal register, and an append-only ledger of invoices and payments.

In use on my Mac

Fieldwork runs on my own Mac with research switched on. Its workspace holds 92 company research records, 109 contact records, 109 prepared outreach drafts and 361 sourced evidence rows, with a buyer referral agreement confirmed and on file.

Built as a desktop product

• Native Mac app: a Swift, AppKit and WebKit window around a bundled Python runtime, so it needs no Python install. Apple Silicon, macOS 14 or later, signed locally but not notarized by Apple.
• Data kept separate: the workspace lives outside the app, with automatic backups, and a one-time migration moved the original database across with its records intact.
• Standard-library Python and SQLite with a plain HTML, CSS and JavaScript interface. Customer builds ship without any data, and a read-only fictional demo can be explored safely.
• Tests: 89 backend and workflow tests and 3 desktop tests (startup without system Python, migration that preserves records, rejection of a corrupt database).

The website

• Brokerage site: listing search by filters or by a sentence like “3-bed in Elm Hollow under $900k with a garage”, featured and sold listings, neighborhoods, team, reviews, and valuation and contact forms.
• Blog and SEO library: 48 guides, from neighborhood profiles and comparisons to buyer and seller explainers, each with quick answers, FAQs and structured data, plus category filters and live search.
• Calculators: monthly payment, affordability and seller net proceeds, plus listing-alert sign-up.
• Website security report: plain-language findings on a hacked site (hidden spam links, a poisoned robots.txt, an outdated CMS) and a three-phase cleanup plan.
• Case study: the pitch behind it, built as three optional layers so the firm never has to throw away what works.

The AI tools

• Team Hub: leads, approvals and activity in one dashboard, every tool opening inside it, and a view-as switcher for each agent.
• 24/7 lead responder: replies by text and email in under a minute, qualifies the lead and books a showing on the right agent's calendar.
• Review engine: day 0, 2, 7, 30 and one-year touches after closing, and reviews reused on the site and social.
• Listing launch kit: MLS remarks, social posts, an email blast and open-house copy from one set of details, with a fair-housing screen.
• Virtual staging, vertical video ads and a social engine that drafts a week of posts and video scripts for approval.
• Past-client emails with a monthly home value and equity note, and market reports for eight neighborhoods.

The problem

The big wedding apps, The Knot, Zola and WeddingWire, earn money by selling couples' details to vendors and pushing registries, so their design nudges spending up. The couples who most need help are those with under about $15,000 to spend (the US average is around $33,000), usually paying for it themselves and planning without a planner.

Thrifty Vows earns money only from the couple, so it can be honest about spending less. The plan is a free core app and a one-time Pro unlock for sync, sharing, exports and widgets, with no subscription.

What it does

• Budget: a total split into 13 categories by a recommended budget-wedding allocation, with estimate, final cost, amount paid and due date on every expense.
• The guest-count lever: a calculator separates fixed costs from the ones that grow with each guest, and shows in dollars what adding or cutting people does.
• Guests and RSVPs: sides, A and B lists, plus-ones, meals and households, swipe to RSVP, and CSV export.
• Checklist: tasks dated backwards from the wedding and grouped by phase. Move the date and the open tasks move with it.
• Vendors, seating and DIY: quotes compared side by side, with a booking written straight into the budget; tables with capacity warnings; and DIY projects that weigh making against buying.
• Savings tips: concrete tips, each with a typical saving, that add to a running total on the home screen.

The 2.0 redesign

Version 1 worked but looked like stock iOS. Version 2.0, "Blush & Petal", was designed first as a mockup and then built into the app: rose for actions, blush cream behind everything, sage for money saved and champagne for neutral highlights, with serif headings over rounded body text. It added a custom icon of interlocking rings, a dark mode with its own plum palette, and a native Mac version of the same app.

Where it goes next

• 1.1: iCloud sync and partner sharing, contacts import, PDF export and a countdown widget.
• 1.2: a shareable RSVP link, a day-of timeline and payment reminders.
• Later: anonymous price benchmarks by city, and swap suggestions such as a brunch reception instead of dinner.

Measures of success

Couples set a budget and add at least ten guests in their first week, the median saving logged per couple, Pro conversion, and an App Store rating of 4.7 or better.