When a new client asks how I work, I tell them early that I use custom AI agents. Some people relax when they hear it. Others get nervous. Both reactions make sense, so here is what it actually means on a project, and where the line sits.

The short version

I’ve built websites since 2016, more than 150 of them. The way the work gets done has changed since then. Now I write the spec, custom agents I’ve set up do much of the building and testing, and I review every change before it ships.

The agents don’t talk to clients, and they have no say in what gets built or when it’s finished.

What the agents do

I run four roles, each set up for my projects, my conventions and my checklists.

The builder agent writes code from the spec. The test agent writes and runs tests. The review agent reads each change and flags problems. The ops agent handles deployments and keeps an eye on things once they’re running.

Where they help most is volume. The MEFMA event app has 63 automated unit tests. Fluffy’s café workspace has 49 test files. My own product, Unmu, has 1,886 automated tests passing. Writing that many tests alone, by hand, used to be the first thing a small project cut. With agents it’s routine. That doesn’t make the tests right by default. I still read what each one checks, because a test that checks the wrong thing is worse than no test: it tells you everything is fine.

Deciding where AI doesn’t belong

The most useful decisions on a project are often about where not to use AI at all.

Dr. Ehab Hamarneh runs an Arabic coaching academy, Be You Training, and I built the support desk behind it. Tickets get sorted into categories like Payment, Courses and Password. That sorting is deliberately keyword-based: it’s free, instant and predictable, and a support agent can see exactly why a ticket landed where it did. If a person changes a category by hand, the system doesn’t overwrite their choice.

The chat widget on the site works the same way. It searches the academy’s own knowledge base first. If an article matches, it answers from that article, with no AI call at all. Only when nothing matches does it either try an AI answer (if that’s switched on) or hand the customer to a person, which opens a real ticket. Every AI call it does make is logged with its token usage, so the cost is visible.

A model could have done all of that. It would have been slower, cost money on every message, and been harder to explain to the support team. Choosing the plain option is my job. Agents are good at doing what they’re asked, and they rarely ask whether the task needs AI in the first place.

Deciding what’s safe

The same desk receives newsletters and sales pitches alongside real customer email. Those junk messages are closed and tagged, never deleted. Deleted mail can’t be recovered, and a real customer misjudged as junk would vanish without anyone noticing. Closed and tagged, they stay searchable and one click from being reopened.

Arabic needed its own care. Customers spell the same course name several ways: with or without a shadda, with different forms of alef, with Arabic or Western digits. The tagging normalises all of that before matching, so one rule catches every spelling. It only ever adds tags. An agent’s own tags are never removed.

None of these choices is clever. They come from thinking about what could go wrong for this particular business, and that thinking is the part I don’t hand off.

Refusing to fake it

On the MEFMA event app, guests were meant to get a QR code in their table email. For a while, the real per-guest QR from the booking system wasn’t verified yet. The easy move was a placeholder QR that looked right. The checklist said the opposite, in plain words: do not render a fake QR. The option stayed switched off until real codes were confirmed.

The same goes for test results. When I load-tested MEFMA’s awards game with 1,000 simulated players, the first attempt, run from a desktop, failed: connections timed out after 203 live streams opened. That failed run is kept in the report as evidence, next to the run that passed. The report also says what the passing test doesn’t prove, such as venue Wi-Fi or real phones. An agent can write that report. Deciding that the limits paragraph stays in is mine.

What you deal with

You deal with me. We talk on WhatsApp in plain language. I write a short spec you can read and change before anything is built. You see a demo every week. After launch, I support what I shipped.

If something breaks, you don’t get “the AI did it”. You get me, and I answer for it, because I reviewed it and shipped it.

What this means if you’re hiring someone

Most builders use AI tools now, whether they mention it or not. The useful questions are about the work around the tools. Ask who reads the code before it goes live, and how it’s tested. Then ask who you call when it stops working at 9pm on a Thursday.

For my projects the answers are short: I read it, the tests are in the project, and you call me.

If you have questions about how this works on a real project, you can ask me on WhatsApp.

Related work: See the systems this applies to

A live game at a gala has one awkward property: everyone acts at the same moment. The screen says “Category starts now”, and a few hundred phones send a request within the same second. If the server stumbles there, it stumbles in front of the whole room.

For MEFMA’s awards night I built Guess the Winner, a prediction game guests play on their phones during the ceremony. It was built for about 500 guests. Before trusting it with a ballroom, I wanted to know what would happen with twice that number. This is how the test went, including the part that failed.

How the game works

Guests open a link, enter their table representative’s name and table number, and they’re in. There are three rounds: FM Client Awards with four questions, FM Service Provider Awards with five, and FM Supplier Awards with three. Twelve questions in total.

The host controls everything from a separate, password-protected screen. Starting a question puts it on every guest’s phone. Guests pick one of the four or five nominees, and their pick is saved as a draft until the host ends the question. Then the picks are submitted together.

Guests never see a leaderboard or the correct answers. The answer key is never sent to the browser at all, so nobody can find it by poking at the page. Scores are private to the host, with round totals, overall totals and CSV exports. The guest with the most correct predictions wins.

What could go wrong

Three moments carry most of the risk. The first is joining, when hundreds of people arrive at once. The second is the switch to a new question, when every phone has to update. The third is a round boundary, where phones may lose and regain connection.

So the test had to cover all three, through the same public HTTPS address guests would use, against the same server code. It also had to leave the real event data alone.

The first attempt failed

My first run used a load generator on a desktop machine, sending traffic over the internet to the live server. It joined all 1,000 simulated participants. Then it started opening the live connections that keep each phone in sync, and those started timing out on the way through Cloudflare, the service that sits in front of the website. It stopped after 203 of those connections opened. The slowest join took 7.7 seconds.

The public site kept answering its health checks the whole time. That suggested the bottleneck was the test machine and its route rather than the server. But a suggestion isn’t a pass. The run didn’t prove synchronisation, so it’s recorded as a failure and kept in the evidence alongside the run that passed.

The test that passed

The second run, on 10 September 2026, generated the load on the server itself, and still sent it through Cloudflare and the public web address. It used an isolated game on the same server with the same deployed backend code. Live participants and answers were not touched.

The simulated players behaved like the real guest app, including the small random delays real phones add and the backup checks the app makes when a live connection drops. They saved answers in bursts and played all three rounds.

Here is what it measured:

• 1,000 players joined at once. The slowest join took 761 milliseconds, under a second.
• All 1,000 stayed connected for live updates, and 50 were deliberately dropped and reconnected.
• On every one of the 12 question switches, all 1,000 phones caught up, the slowest in 572 milliseconds.
• At round boundaries, everyone was back in sync within about two seconds, including 50 players cut off on purpose for one and a half seconds.
• The test also ran the game’s optional 60-second timer: when a question expired, all 1,000 phones showed it closed within about half a second.
• 12,000 answers were stored, exactly 1,000 per question, with nothing left unsaved. The database check came back clean.
• A separate monitor checked the public site 92 times during the run. None failed.
• There were no unexpected disconnects and no restarts, and the whole run took 89.3 seconds.

Afterwards, the temporary test entry point was removed from the server.

A second test, for the voting rules

Speed isn’t the only risk. A game can be fast and still count votes wrongly. A separate test, with 500 simulated players on an isolated local setup, went after correctness.

It sent identical vote retries and checked they weren’t counted twice. It sent stale changes and checked they were rejected. It raced 500 votes against the host closing a question: 250 got in, 250 were refused, and the totals reconciled exactly. It restarted the server mid-game and checked that sessions, votes and scores survived. All 6,000 answers were stored and every score matched, including the rule that either of two joint winners earns a point.

What these tests don’t prove

The 1,000-player report says this plainly, and I think every load test report should. The load ran on the server. It does not reproduce 1,000 physical phones, venue Wi-Fi, how each device renders the page, every internet route, or hours of operation. Zero issues on the night can’t be guaranteed from a test like this.

The 500-player test has its own limits: it ran on a single local machine, with simulated players, and it didn’t cover the live hosting setup or venue Wi-Fi.

Writing those limits down can feel like weakening the result. In practice it tells the organiser what’s left to manage on the day, like the Wi-Fi in the ballroom, so a big number doesn’t stand in for certainty.

If your business has a rush moment

Plenty of businesses have a moment where everyone arrives at once: a ticket release, a product drop, the start of a live session, a sale that opens at 10am. If yours does, that’s the moment to test, on the real route, with honest limits written next to the result.

The questions I’d ask are simple. How many people at once, realistically and at worst? What do they all do in the first ten seconds? What happens if some of them lose signal?

If you have a moment like that coming up and want a second opinion on testing it, you can reach me on WhatsApp.

Related work: MEFMA Event Operations

The hard part of seating a gala dinner is that the guest list never stops changing. The room has a fixed number of tables. Sponsors expect to sit near the stage, and a company that bought ten seats wants them together. Or spread out, if the evening is meant for networking.

The usual tool is a spreadsheet, and it works for the first draft. Then a booking is cancelled, someone corrects their email, a company sends a substitute, and the spreadsheet and the booking system start to disagree. On the night, the door team is left checking names against whichever copy they printed.

I built MEFMA’s event operations app for their gala dinners and awards nights. MEFMA is the Middle East Facility Management Association. This is how the seating side works, and what it took.

Where the guest list comes from

MEFMA sells gala tickets on its WordPress site, through a booking plugin with WooCommerce handling the orders. So the first rule was simple: the booking system stays the source of truth, and nobody retypes a guest.

The seating app has one button for this, Sync confirmed bookings. It imports paid and confirmed bookings only, and it checks payment against the linked WooCommerce order, because the booking plugin’s own paid amount turned out to be misleading. Completed complimentary orders count. Pending, failed, cancelled and refunded orders don’t.

Running the sync again updates names, emails and companies that changed in the bookings. Deleted bookings drop out. Guests the team added by hand stay. The part organisers care about most: a guest who is already seated keeps their table when their registration refreshes. The buyer’s membership level (Strategic Corporate, Corporate or Associate) comes across too, from the membership plugin on the same site.

Laying out the room

The room is built row by row, from the stage to the back. A row holds anywhere from 1 to 20 tables, and a table seats between 4 and 20 people. For one awards gala the layout was 40 tables in four rows of 10, 11, 12 and 7. The app refuses a layout whose rows don’t add up to the room’s table count, and it won’t let anyone shrink a table below the number of guests already sitting at it.

Each table can belong to a zone (Stage, Main, a VIP area) and can carry an optional name such as “Sponsors”. Guests only ever see the number. The name is for the organisers.

There are three views of the same plan: a floor plan you can zoom, a table-by-table list and a searchable guest register. Edit one and the other two follow, since they all read the same data.

Auto-seating you can check before you accept it

The first version of auto-seating was a single button running one formula. I replaced it, because an organiser needs to see what the machine is about to do before it does it.

Now you pick a strategy: balanced networking, keep companies together, or maximum company mix. You decide whether to fill tables tightly or spread guests across every table, and which membership levels get priority near the stage. VIPs always do. The algorithm also balances senior titles (chairs, C-suite, VPs, directors, heads) across tables, so one table doesn’t collect every decision-maker in the room.

It shows a preview first: guests it would seat, tables it would use, how many people sit with a colleague, how mixed each table is. Nothing changes until someone clicks Apply. Manual seats are kept. Capacities are never exceeded. If the room is too small, the preview lists who would be left unseated instead of squeezing them in somewhere.

The email and the door

When the plan is ready, each guest gets an email with their first name, table number, the evening’s schedule and a personal QR code. The team edits the subject and body with a live preview, and test sends go out through MEFMA’s own Microsoft 365 mailbox via their WordPress site.

At the door, staff scan that QR with a phone camera. The video is processed in the browser and never uploaded. A scan resolves to exactly one guest, shows their table and zone before confirming, and records the time and the staff member, with an undo. If a code won’t scan, there’s a search by name, email, company or booking reference. Several desks can work at once: arrival counts sync every 15 seconds, and the server stops two desks from checking in the same person. Door staff can have check-in-only accounts.

Guests can also check themselves in on a public page with their registration email, and land on a welcome screen with a large table number.

The QR codes that didn’t match

One part was harder than it looked. MEFMA’s booking invoices already carried QR codes, so the door should accept those too. The first version matched each scan against a code stored with the booking. A test scan missed, because the invoice QR held a different, shorter key. Matching on that key failed as well: the booking system never returned it in its data. Only the website knew which invoice it belonged to.

The fix was a staff-only lookup that asks mefma.org which invoice a key belongs to, remembers the answer and limits how often it asks. On top of that, the sync now reads each guest’s own ticket QR from their invoice page. For one event that linked 235 of 256 guests to an individual QR. The other 21 were on complimentary bookings where the booking system had issued no ticket QR at all, and they still match at booking level.

I mention it because it’s typical. “Scan a QR at the door” sounds like one feature. Making it match the codes already sitting in guests’ inboxes meant asking why each scan failed, again, until the answer was in the data. Until real codes were verified, the QR option in the email stayed switched off. Showing no QR beats showing a fake one.

What the organisers get at the end

The spreadsheet does come back, as output. Once the plan is final there’s a MEFMA-branded PDF with a floor plan, table-by-table seating and an alphabetical index, plus an Excel workbook, a CSV and an SVG floor plan. The spreadsheet becomes a printout of the plan rather than the place the plan lives.

“Publish plan” marks the current arrangement as approved inside the team. It doesn’t email anyone. Any later edit sends it back to Draft, so the team can see that something changed after sign-off.

The same app also runs a live awards game for the evening, built for about 500 guests on their phones. Load-testing that game is a separate article.

If you run events

You don’t need a gala to have this problem. Any business that sells seats or sessions in one tool and runs the day from another has the same gap: the list changes and the copies drift. Training days, conferences and workshops all work this way.

The first questions I ask are plain ones. Where do bookings really live? Who changes them, and how late? What has to happen at the door? The answers decide whether you need a full app or just a reliable sync and a good check-in page.

If your events work like this and you’d like to compare notes, you can reach me on WhatsApp.

Related work: MEFMA Event Operations