Running Greenlight

What Greenlight actually is

One app, but it leans on several other pieces to work. Here is the whole picture.

Every one of these can break. When one does, it is me who gets it back up.

What I've built and kept running

A "change" is a piece of work that was built, tested, reviewed, and released to members.

The app members use

These four are short moving clips on the web version: https://greenlight-running.pages.dev/

• Browse people near you, ranked by shared interests.
• Send a date offer with a day, a time, and a place. Accept, decline, or counter.
• Chat unlocks after a yes. Chat is capped so it stays about the date.
• Build a profile with photos and a short video, trimmed right on your phone.
• Pause your profile, set your weekly availability, dark mode, report a problem.

The part nobody sees

• The brain, the memory, and the locker live in the cloud. I set them up, lock them down, and keep them running.
• Every release: build it, test it, update the memory safely, release it, check it is healthy, have a way to undo it. Several times a week.
• Error tracking so I hear about problems before members email.
• Payments through Stripe, including the billing page where members cancel.
• ID checks through Didit so verified badges mean something.

Keeping members safe and keeping us legal

• Making sure nobody can get into someone else's account or swap photos between accounts.
• Keeping evidence when someone is reported, because New York law requires it, and deleting it when it expires.
• Telling members in New York what they are entitled to when an account is banned for fraud, as the law requires.
• Written policies for copyright takedowns and for child-safety reports.
• Keeping the privacy policy true every time the app changes.
• Bot protection on signup and login.

Design

• Redesigned the whole app and website to the cream look, plus pricing and legal pages, dark mode, colour themes.
• Wrote the design rules so the app looks like one thing, not ten.

Videos and event materials

• 24 member videos edited: captions, end card, audio cleanup, encoding, a private review site for the team.
• 2 demo walkthrough videos with your voiceovers.
• Helped with the event banner: supplied our logo as an SVG and references.
• Signup QR codes.

Emails to members

• The email system itself, plus welcome, confirmation, reminder, and weekly availability emails.
• The post-event invite campaign: 60 members, tested on a phone in light and dark mode before sending.

Admin tools, so support does not need an engineer

• One screen per member: subscription, offers, blocks, photos, notes.
• Buttons for pause, delete, email change, refund lookup, photo review, ID review.
• Email templates and batch send to women, men, or everyone.

These exist so that anyone on the team can handle a member request without me.

Nothing was planned. The foundations were built from nothing

Greenlight did not start with a plan. It started on May 14 as an auto-generated skeleton from a website-building tool: 114 files, no working server, no rules for how the app and the server talk to each other. There was no feature plan, no written agreement for the data, no tests, no design rulebook, no way to measure usage, and no alarm for when something broke. What existed was a shell with nothing behind it. The first members were mostly close friends of the team. They were still real people with real accounts, signing up while all of that was still missing. Every item below is something a product normally has before it opens to real people. Here, each one had to be built afterwards, around live members, while also shipping features.

Days Greenlight ran without it

• Usage measurement (knowing what members actually do)
  119
  Finally existed on Sep 10
• Error alarms (knowing something broke before a member tells us)
  118
  Finally existed on Sep 9
• Written plan and instruction manual (what the product is, how it is built)
  110
  Finally existed on Sep 1 to 13
• Full walk-through test (a robot signs up, browses, pays, every release)
  92
  Finally existed on Aug 14
• Design rulebook (one set of colors, spacing, type)
  72
  Finally existed on Jul 25
• Tracked database changes (every change recorded and reversible)
  66
  Finally existed on Jul 19
• Automated tests (code that checks the code)
  64
  Finally existed on Jul 17
• First security work (locking doors that were open)
  64
  Finally existed on Jul 17
• Legal pages (privacy policy, terms)
  23
  Finally existed on Jun 6

Day 0 is May 14, 2026.

The rulebook that says how the app and the server talk to each other, what every request looks like and what comes back, existed on day one as a 36-line placeholder with nothing in it. It is now over 7,000 lines and covers sign-in, profiles, photos, offers, chat, blocking, billing, ID checks, and safety reports. That rulebook was written after the server was already running, one piece at a time, while fixing whatever the missing piece had broken.

None of this is visible to members. All of it is why the app stays up.

The last two weeks

The team asked what has been done recently. Here is September 1 to September 15.

• Aug 15 to Aug 31: 46 finished changes
• Sep 1 to Sep 15: 126 finished changes

A finished change is a reviewed, tested change accepted into the app. Going live is a separate step I also do, usually within a day or two.

What those 126 changes were

Scroll sideways to see the whole table.

A few examples, in plain English

• Discover now shows people with more shared interests first, and says what you have in common.
• Members can swipe through someone's photos instead of seeing one.
• If someone blocks or unmatches, any pending date offer is cancelled automatically.
• Videos filmed on iPhones now play; broken uploads show a message instead of failing silently.
• The signup city box now understands "NYC" and neighborhood names (the event bug).
• Emails were fixed three times for Gmail dark mode on phones.
• People banned for fraud get the notice New York law requires, and cannot re-register with the same ID.
• Chat messages and offer notes are scanned for scams; the privacy policy was updated before that went live.

The to-do list: done, and still to do

There was no to-do list either. I wrote one on September 5 and 13, 110 days in. Here is where it stands, checked against the live tracker on September 15.

• Signup, discover, offers, chat, settings
  10 done · 9 still to do
• Security and privacy
  8 done · 6 still to do
• Emails and notifications
  8 done · 3 still to do
• Hosting and releases
  8 done · 2 still to do
• ID checks and photo moderation
  7 done · 6 still to do
• Usage measurement
  6 done · 2 still to do
• Testing and release process
  6 done · 5 still to do
• Payments
  5 done · 0 still to do
• App-to-server rulebook and speed
  9 done · 4 still to do
• Admin tools
  4 done · 3 still to do
• Legal and compliance
  3 done · 4 still to do
• Design rulebook
  3 done · 1 still to do

Counts are by item, not by size. One item can be an afternoon or a week.

Still to do

Members

• Blocking or unmatching does not yet cancel an offer that was already accepted, only pending ones.
• A member can turn phone alerts on but there is no way to turn them off.
• A "save your profile as a draft" feature is built but switched off until we decide to launch it.
• Eight icon-only buttons have no label for screen readers.

Safety and moderation

• No admin button yet to undo an approved ID check.
• No admin screen yet for evidence holds on reported content; today that is done directly in the database.
• A policy decision is still open: when the same person is reported repeatedly, how long do we keep the evidence?
• The scam scan on chat has no timeout, so a slow outside service could stall it.

Security

• Temporary upload links are not yet locked to one purpose and one person.
• The staff permission system exists but has no screen to use it from.
• Rate limits do not yet cover file uploads.

Emails

• Some email graphics use a green that disappears in Gmail dark mode, and the automated check that should catch it does not look at images.
• A safety-notice email keeps a member's address longer than our own deletion policy says.

Behind the scenes

• Two speed measurements still to run on the Discover and chat screens now that the database changes are live.
• Test coverage minimum is set far too low and needs raising to what it actually is.
• One flaky test, a handful of dead files, and a large admin export that can run an unbounded database query.

Every line above needs an engineer. None of it is the support desk.

When things break

Nobody sees this work. It happens at night and on weekends, and it does not wait.

In all three cases there was no gap of days between the report and the fix. Most software teams take several days, often a week or two, to get a reported bug fixed and released. Each of these was live the same night it was found, by one person, around a day job.

How available I am

I am always available. I am just not always at full speed.

During the day I am at work, and part of it I am out walking the dogs. From my phone I can do most of the job: read messages, check a dashboard, answer a question, review a change, push a small fix. It all goes slower there. And I cannot walk the dogs and work the phone at the same time, so those stretches are dead time.

Two kinds of work cannot happen on the phone at all. Video editing needs the PC, full stop. Anything big needs it too: a major overhaul, screenshotting the app across a whole flow, building several pages for one feature. That is desk work, and it happens evenings and weekends.

Being reachable is not the same as being at full speed.

The support desk is a separate job

I can be the full-stack engineer. Front end, back end, releases, fixes, security. That is the job I am doing. The support desk is its own job, and right now it lands on me alone, on top of that. I can still help with it. I cannot be the only person doing it.

Scroll sideways to see the whole table.

When a real bug shows up in that inbox, tell me. That is the handoff. Everything else in that inbox is not engineering.

The ask