Bridgify

Inspiration

Freelance web designers don't lose money on the big projects. They lose it in the group chat. A client texts "can you make the header blue?", then "also swap the hero photo", then "oh and add a pricing page?" Every one of those messages needs a reply, a decision about whether it's in scope, a count against the revisions in the contract, and a note somewhere so it actually gets done. Most freelancers handle this from memory at 11pm, and scope creep wins.

We wanted the freelancer to only have to do the actual website work. Everything else, like answering, tracking, counting revisions, and spotting extra scope, should happen on its own, right inside the iMessage thread the client already uses.

What it does

Bridgify is an assistant that sits in the client's iMessage group and an owner dashboard behind it.

Understands the agreement. The freelancer pastes their contract or uploads a text PDF. Bridgify extracts what's included, what's excluded, revision terms, and dates, with a source quote for each one. Nothing counts until the owner confirms it.
Handles routine requests automatically. When a client asks for an eligible change, Bridgify checks it against the confirmed scope and the owner's automation rules, reserves a revision, creates one actionable task, and replies in the chat. The owner doesn't need to step in.
Asks clarifying questions. If a request is missing the page, element, or wording, the bot asks, then attaches the answer to the right open request without duplicating anything.
Answers status questions honestly. "Is the contact page done?" gets answered from real task state. It never claims work is finished when it's only been accepted.
Escalates exceptions privately. Out of revisions, new scope, deadline changes, or disputes go to the owner's Needs Attention queue with the original message, scope evidence, and suggested options. The client gets a neutral "we'll get back to you." No prices or internal notes leak into the group.
Turns extra scope into approved work. The owner drafts a proposal with deliverables, price, date impact, and expiry. The client approves that exact version on an authenticated page. A "yes" in chat doesn't count. Approval updates scope and creates the tasks in one step.

How we built it

Photon connects Bridgify to the real iMessage group. Incoming messages are verified, saved, and de-duplicated before anything else happens.
Gemini reads each message and returns structured output: what kind of request it is, which confirmed target it refers to, and evidence for that match. We validate every response before acting. The model can suggest, but it can never grant permission on its own.
The core acceptance step runs as one database transaction. It rechecks identity, policy, and scope, reserves a revision, creates the task, writes the audit record, and queues the reply. If anything fails, everything rolls back. Two simultaneous requests can't both take the last revision.
A background worker handles contract extraction, message analysis, and outgoing replies, so slow model or network calls never block the app.
The dashboard shows Actionable Tasks, Needs Your Decision, Awaiting Client Approval, the revision ledger, and a read-only view of the client thread.

Built on Photon 2.0

Bridgify only works because it lives where freelancers and clients already talk. Clients won't log into a portal or learn a new tool, but they will text. Photon 2.0 lets our agent be a real participant in that conversation instead of another app clients have to be convinced to use.

How we use Photon:

A real phone number in the client's iMessage group. The freelancer adds Bridgify to the project group chat the same way they'd add a person. The client keeps texting exactly as before, and the agent reads and replies in that same thread.
Verified, project-scoped intake. Each Photon group is linked to exactly one project. Incoming events are verified, saved before we acknowledge them, and de-duplicated, so a repeated delivery never creates a second task or uses a second revision. Messages from the bot itself or the owner are recognized and never treated as new client requests.
Identity-aware behavior. We map each Photon sender to a known role: client requester, approver, owner, or the bot. Only a verified client in the linked group can trigger work. Unknown numbers, changed group membership, and messages from before activation are held for the owner instead of acted on.
Group social context. A group chat is messy. People send three asks in one text, correct themselves later, reply to old messages, or just say "thanks!" Bridgify decides when to speak and when to stay quiet. It combines mixed requests into one clear reply, asks one focused clarifying question, and doesn't respond to every emoji.
Agent and human working together. Bridgify handles the routine messages on its own. Anything involving money, deadlines, or new scope goes to the freelancer's dashboard, and the client gets a neutral holding reply in the thread. The human stays in charge of commitments; the agent handles everything else.
Reliable outgoing messages. Every reply is saved as a pending send together with the action that caused it, then delivered by our worker through Photon. If a send times out and we can't tell whether it went through, we mark it uncertain and show it on the dashboard instead of risking a duplicate text to the client.

Because Photon is multi-channel, the same agent can later run over SMS, RCS, WhatsApp, or email for clients who aren't on iMessage. The project, rules, and revision ledger stay the same; only the channel changes.

The Startup Opportunity

The problem is huge and unglamorous. Freelance designers, developers, and small agencies run client work through text messages. Scope creep, forgotten requests, and revision disputes cost them real money and real clients, yet the tools built for this (project portals, client dashboards, change-order software) all fail the same way: clients don't use them. Bridgify solves this inside the channel clients already use, so there's nothing for them to adopt.

Who pays. Our first customer is the solo freelance web designer with several active clients and a contract that says "two rounds of revisions." Next are small studios and agencies, where team roles and shared queues matter, and then any service business that handles scoped client work over text: video editors, brand designers, contractors, consultants.

Business model. A monthly subscription per freelancer, priced by active projects, with a free tier of one project so people can try it on a real client. Teams pay per seat. The pitch is simple: if Bridgify catches one piece of unbilled scope a month, it has paid for itself, and approved add-ons are tracked right on the dashboard so users can see the money it recovered.

Built-in distribution. This is what we're most excited about. Every Bridgify project puts the product in front of a new person: the client. Clients watch a freelancer's group chat suddenly become organized, with requests confirmed, revisions counted, and add-ons sent as clean proposals. Many clients are themselves business owners who hire other freelancers or do client work of their own. Each project is a live demo to exactly the right audience.

Creator-led growth. Freelancing has a large creator community: designers and developers on YouTube, TikTok, and Instagram who teach pricing, contracts, and "how to handle difficult clients." Scope creep is one of their most common topics. Bridgify gives them something concrete to show: a real client thread being handled automatically, plus the dashboard of extra revenue it captured. We'd go to market through partnerships with these creators, with referral codes and shareable "scope saved" recaps. Creator-led distribution platforms like SideShift are a natural way to run those campaigns at scale.

Why now. Two things just became possible together. Language models can finally interpret messy, informal client texts reliably enough to be useful. And platforms like Photon let an agent live natively in iMessage and other messaging channels with a real number. Before both existed, the only option was asking clients to change their behavior, and they never do.

Defensibility. Over time, Bridgify builds a record of how each freelancer's clients ask for work, what's in scope, and which requests become paid add-ons. That history makes automation more accurate for each user and makes the product hard to switch away from. The trust model, where AI interprets but rules and humans commit, is what lets freelancers comfortably hand it their client relationships.

Challenges we ran into

Making AI safe to act on. Getting Gemini to classify messages was easy. Making sure a confident but wrong answer could never become a commitment to a client was the hard part. We ended up treating the model as a suggestion engine, with all real decisions made by checked rules.
Messy conversations. Clients send three requests in one text, correct themselves mid-thread, or answer a question from an hour ago. Matching follow-ups to the right open request was the hardest logic we wrote.
Counting revisions correctly. Retries, duplicate webhook deliveries, reopened tasks, and cancellations can all double-charge a revision if you're not careful.
Not sending a message twice. If a send times out, you don't know whether the client got it. We track uncertain delivery instead of blindly resending.

Accomplishments that we're proud of

A real client iMessage turns into a tracked task and an accurate reply, with no owner involvement.
The bot says "accepted for the designer to do," never "done," unless it actually is.
Extra scope can't slip through on a casual "sure." It has to go through an explicit, versioned approval.

What we learned

Most of the work in an "AI agent" isn't the AI. It's permissions, transactions, idempotency, and deciding exactly when the system is allowed to make a promise on someone's behalf. We also learned to build a manual version of the acceptance pipeline first and add Gemini on top, which made debugging much easier.

What's next for Bridgify

Revision rounds that match how contracts are actually written (one round, many messages)
Private iMessage alerts to the owner for decisions
Team roles so collaborators can take tasks without setting prices
Client image uploads for "replace this photo" requests
A policy simulator to test rules without affecting real clients