Monkey Mail
What it is, and why it exists

What Monkey Mail actually does

A member of the Communications Team writes a newsletter out of blocks — a banner, text, story cards, buttons, an events list — picks who it goes to, sends a test to themselves, and presses Send. Every recipient gets their own separate email, addressed only to them.

Underneath that, four things are happening that a general-purpose email tool does not do. The audience is a live query against iSAMS, the school's contact database, so a pupil who enrolled this morning is already in the Year 7 parent list this afternoon. The message is compiled into email HTML that survives Outlook, Gmail and iOS Mail rather than into a web page that happens to be emailed. It sends through the school's own Microsoft 365 tenancy, so the message comes from communications@wycombeabbey.ac.th and never leaves the school's systems. And afterwards it reads the bounce reports back out of that mailbox, works out which address failed and why, and tells you which parent to ring.

Where the idea came from

Monkey Mail was Rolly Alfonso-Maiquez's idea. He is the school's Head of IT, and it came from working alongside the Marketing and Communications team rather than from a brief handed down to them.

The pain points were ones he had heard about, watched and run into himself: the work of getting a single message reliably to every parent, and to external contacts, and to all staff, using tools that were never designed for a school's contact records or a school's obligations. Knowing which of those frictions were worth building around — and which were just how email is — is the part that could not have been specified from outside.

He also came to it with practice. By September 2026 he had built more than twenty KEYSTONE apps for the school, so the first conversation started from a realistic idea of what a working first version needed to do and what could wait.

And he brought a method. BUILD is a five-step design-thinking framework for turning a school problem into something that works — Begin with a real problem, Understand the need, Iterate with confidence, Launch a useful first version, Develop it with others. This build followed it closely enough to be a fair demonstration of it: it began with one frustration, it was clarified with the people who would use it, it was corrected many times in the space of a day, it launched as a working link that had sent to real families, and it is now being developed with the team that sends from it.

The BUILD model: rolly-folsea-2026.ateneo.workers.dev — Dr Rolly Alfonso-Maiquez, presented at FOLSEA 2026, Jakarta.

How it actually got built

This was built in the open-ended, conversational way people now call "vibe coding" — describing what was needed in plain language, watching it get built, using it immediately, and correcting course. One person working with Claude Code, in one continuous conversation.

It opened at 10:59 in the morning of 18 September 2026, and not with a request for code. The first message set out what the app was for, who would use it, and — the part that mattered most — how it should be structured: a separate Worker rather than another module bolted onto App-25 Pupil View, because only the Communications Team would use it and Pupil View should not have to carry it. The audience would come from Pupil View's existing iSAMS binding instead of a second connection to the school's records. And the editor had to be, in his own capitals, ÜBER GOOD — good enough to take an exact paste from Word with the images intact. That message ends with two words: "Q&A ME".

The first commit came four and a half hours later, at 15:25. Those four and a half hours were spent deciding things, and every structural decision taken in them is still standing: the separate Worker, the service binding, the single-recipient send. About forty-five minutes after that first commit the first test email arrived in a real inbox. That evening a real campaign went to two people. The following morning it went to fourteen Nursery families, and just after eleven it went to three hundred and forty-four.

Nothing in that sequence was a rewrite. The shape of the app changed constantly — story cards grew multiple buttons, campaign types acquired their own unsubscribe rules, the preview split into phone and desktop, the whole type system was re-derived from a single base size after a long argument about what a newsletter should look like on a phone — but the send path written in the first hour is the send path that delivered all 360 emails.

The work was not linear and it was not passive. A large share of it was the product owner using the thing, disliking what he saw, and saying so. "REALLY?????????" is a real message in the transcript, about a reading-time estimate that claimed five words took a minute to read. "waste of space!" is another, about a settings panel. "it's like another language ???" is what produced the plain-English notice that now sits above the font controls. The app is noticeably better in the places where the feedback was bluntest.

From empty folder to 344 families

Twenty hours and twenty minutes from the first line of code to the whole parent body; twenty-four hours and fifty minutes from the first message. Not that many hours of work — the clock includes a night's sleep — but that much calendar. All times are Bangkok, which is where every one of them happened.

Hours actually spent

The calendar span flatters the build, because it contains a night. What the conversation log records is 6,138 timestamped events across six sittings, and those sittings can be measured rather than estimated.

About 12 hours of active work, or 16½ hours counting whole sittings end to end, inside a 26½-hour calendar span. The 12-hour figure excludes any gap longer than ten minutes, the ordinary convention for active time; the 16½-hour figure measures each sitting from its first event to its last. Both come from timestamps rather than recollection. An earlier version of this page estimated 25 to 30 hours — that was a guess, and it was roughly double.

The shape of that table says more than the total. One sitting ends at 00:55 and the next begins at 06:06, and two of the six fall squarely outside a working day — which is the concrete version of the point made further down about why none of these hours carry a price.

What exists now

The build figures above are regenerated from git every time this page is deployed — last updated 19 September 2026 at 19:14 Bangkok — so they describe the app as it stands rather than as it stood when this was written. The production figures below were read from the live database on 19 September 2026 and are refreshed by hand. None of it is an estimate unless the page says so.

Zero to eighty, and never to a hundred

The product owner has a way of describing how a build actually goes, and it is worth setting the record against it, because this build followed it almost to the letter.

80% — 18 September, 18:01

Seven hours after the first message, and about four hours of actual work into it, the editor existed, the compiler produced an email that survived Outlook, and a real campaign went to two real people. That is "you've basically got a working app", and it arrived roughly when his model says it does.

Then the part the model insists on: other people

What follows 80% in his description is not more building, it is testing with colleagues — D, develop it with others. That is what the record shows: twenty-eight test sends, tests to colleagues and to demonstration parents, and a review by the Marketing and Communications colleague who would actually be doing the sending, run over LINE. It is also where six of the nine defects on this page were found. Not one of them was found by reading code.

90% — 19 September, 11:48

The "big edits, big tweaks": the whole type scale re-derived from a single base size after a long argument about what a newsletter should look like on a phone, the preview defects, the confirmation gate, campaign types carrying their own unsubscribe rules. Then the thing it was built for — 344 of 344 delivered, no failures.

99% — 19 September, and continuing

The "further tweaking", almost all of it prompted by what a real send revealed rather than by anything anyone planned: bounce classification that tells a full mailbox apart from a wrong address, human clicks separated from a link scanner's, a send report that names who to ring, a standing list of problem addresses carried between campaigns, resend-to-failures, and link checking before send.

100% — not reached, and not aimed at

By his own account there is no such point: "there's always something to tweak so i don't aim for perfection and finality — just to a point that users are happy, functions are working, things are working well." By that definition Monkey Mail was finished at 11:48 on 19 September, and has been improved every hour since.

Those percentages are a reading of the record against his own model, not a measurement — there is no scale that tells you an app is 90% done. The times and the hours behind them are measured; the labels are a judgement.

Quoted from rolly-folsea-2026.ateneo.workers.dev/about, where the wording is published in full alongside the question that prompted it.

Reality checks, at intervals

Every so often the product owner stops and asks where the build actually is. The rule for answering is that nothing gets estimated if it can be counted — and both times so far, the counted answer has differed from the felt one.

19 September, afternoon — "how can I be super sure they arrived?"

The honest answer, that afternoon, was that the app could not say. sent meant Microsoft had accepted the message and taken responsibility for it. Bounces supplied the negative signal, but silence from a receiving server is weak evidence: a message quietly dropped, or filed straight into a junk folder, looks exactly like one read over breakfast.

Checking that answer properly turned up two things. The first was a defect. Verifying the report against the database rather than reading it back showed the engagement figures were wrong — the report claimed 253 clicks by people and no machine activity, when the database held 45 human clicks and 210 by a link scanner, correctly classified all along. Every click query was missing the filter its sibling open queries had, and it had been naming a scanner in Hong Kong as the first person to read the newsletter, nought seconds after send.

The second was that the question had become answerable since the last time anyone checked. Microsoft had released a message trace API on Graph, generally available since January 2026, supporting an application permission — which is exactly how this app authenticates. It was built that afternoon. The first real run appeared to fail: the browser gave up waiting, because the code was issuing one database write per recipient and a whole-school send meant 344 of them in sequence. The data had landed perfectly well. Only the patience had run out.

Read from Microsoft's own message trace at 16:42 Bangkok on 19 September 2026 — the authoritative record of delivery to each recipient's mail server, independent of anything this app recorded.

19 September, evening — "almost 40 hours, and 95%?"

Two parts to the question, and the record disagreed with both.

On the hours. It felt like forty. It was not.

Thirteen hours. It feels like forty because it crossed two days and a midnight, which is exactly why the question was worth asking rather than answering from memory.

On the 95%. The sending engine is there or close to it: 360 emails, no failures, two real sends, and Microsoft's own message trace independently confirming 338 delivered and nothing filed as spam. Bounces classified, households reachable, links checked, engagement honest about machines.

The product is not, and the gap turned out not to be code at all. The audit log answers the question nobody had asked — who has actually used this?

Which puts the honest figures at roughly 99% for the engine and 90% for the product, with most of the remainder discoverable only by watching someone else send the October newsletter start to finish while the person who built it sits on their hands and writes down every hesitation. That is the next action, and it will produce more improvement in an hour than a day of code review would.

Pulse checks get added here as they happen, with whatever they turned up, including the parts that were uncomfortable. A check that only ever confirms the current belief is not a check.

What the product owner actually contributed

"Vibe coding" invites the assumption that someone described a wish and a machine granted it. That is not what the record shows. The code was written by Claude; almost everything that made the code correct came from the product owner.

Product owner and lead designer is the accurate description of the role Rolly Alfonso-Maiquez held here, and both halves matter. As lead designer he decided what the thing should look like and how it should behave — the block model, the phone-first preview, the type scale, the wording of the warnings. As product owner he did the job that in a larger team nobody else is allowed to do: he set the scope, ranked what got built next, gathered and weighed feedback from the colleagues who would use it, and accepted or rejected the work. Someone has to decide that a thing is good enough to send to 344 families. That decision was his, and he made it only after watching fourteen arrive.

He set the non-negotiables before any code existed

Two rules were stated at the outset, in capitals, and never relaxed: never send as CC, because families must not see each other's addresses; and never send to anyone without being told to. Both are now enforced in code and guarded by tests. The send function takes exactly one address and has no code path that can attach a second. Those rules did not emerge from the build — they constrained it from the first hour, which is why they hold.

He insisted on a staged send, and it paid for itself immediately

Given a working app and 344 waiting families, the decision was to send to fourteen Nursery families first and look at the result. That was his call, not a suggestion he accepted. It surfaced a case nobody had modelled: two parents with one child in Nursery and another in a different year group, who would have received the same newsletter twice. The app now detects the overlap before every send and offers to skip the people who already have it. A single-shot send to 344 would have found that bug by annoying two families.

He found most of the real defects — by looking, not by reading code

Nine defects survived into something a parent could have received, or were only findable in real data. Six of the nine were caught by the product owner, looking at output.

Scroll the table sideways to see every column.

Four further defects were introduced by Claude during the build and corrected the same day, three of them after the product owner pushed back on a confident claim that turned out to be wrong. One of those was the assertion that email clicks cannot be faked. They can. Forty-two of them were.

He tested like someone who had something to lose

Twenty-eight test sends before the first bulk send. Tests to himself, to colleagues, and to demonstration parents. Approval ran through a LINE chat with the Marketing and Communications colleague who does the sending, who reviewed and edited the September newsletter before it went out. Before pressing Send on 344 he asked whether the window had to stay open, whether the laptop had to stay awake, whether both parents would each get their own copy, and whether the comma-separated list on the confirmation screen meant the addresses would be visible to each other. Every one of those is the right question. The last one is the question that would have caught a CC bug if there had been one.

He corrected the machine when the machine was wrong

Told that user roles had never been configured, he replied "huh?" and produced the table showing all three roles configured since 18 September. He was right. Shown sample data for a report, he spotted instantly that it had borrowed a real family's name and invented a spouse and a phone number to go with it, and said so at once. Fixing that exposed a real bug underneath: the household lookup was grouping contacts by failed address rather than by family. A fabricated example had been hiding a real defect.

What the defect record actually shows

There is a pattern in the nine defects and it is worth naming, because it predicts where the next one will be.

Almost every defect lived at a seam between two components that were each individually correct. The editor knew the subject line; the compiler knew how to draw a banner; the subject never travelled between them. The preview knew it was 600 pixels wide; the email knew it switched to phone layout below 620; nobody had compared the two numbers. The app had a stylesheet; the email had a stylesheet; injecting one into the other drew dividers nobody asked for. The tracker knew how to rewrite links; the archive URL was a token that could not be resolved at click time.

Meanwhile the part everyone was frightened of — the send path, the code that could email the wrong thing to 344 families — has never produced a production defect. It got the tests, the review, the staged rollout and the paranoia, and it has a perfect record. The bugs went where the attention wasn't.

What a commissioned build would have cost

If the school had gone to a development firm and asked for an email platform that does what Monkey Mail does — the live iSAMS audience binding, the block editor, the email compiler, individual personalised sending through the school's own mail system, bounce classification and the reporting — this is roughly the shape of that project.

Scroll the table sideways to see every column.

Run in sequence that is 28 weeks. With the usual overlap between phases, a team of about eight would ship a comparable version one in roughly six to seven months. Every one of those phases happened here too — compressed into two days and folded into one conversation instead of eight scheduled handoffs.

Head-to-head — build it this way, commission it, or buy it

Three ways the school could have arrived at a bulk email tool. The third column is Mailchimp Standard, the tier that realistically matches this team's needs, included because a cost comparison that leaves out the option most schools actually take is not a comparison at all.

Scroll the table sideways to see every column.

None of these figures are invoices. This build was never billed by the hour, and the commissioned-team column is a modelled benchmark — a hypothetical staffing plan priced with real published salary data, not a quote from an actual firm. The person-hours and phase durations are this page's own assumption. The labour cost uses a blended fully-loaded rate of about $124 per hour, derived from 2026 Bay Area role averages loaded by the 1.4× multiplier commonly cited from US Small Business Administration guidance. The "this build" column is an honest approximation of unlogged activity, and its hours are the only figure in it worth leaning on. Both columns exist to make the comparison legible, not to the dollar.

What the tooling actually cost

The build ran on Claude Code, on a Team Premium seat. Anthropic prices a Team standard seat at $20 per user per month billed annually, or $25 billed monthly; a Premium seat is $100 annually or $125 monthly, and carries five times the usage of a standard seat. The seat costs five times as much and gives five times the room.

That seat is not a Monkey Mail expense. It is a standing subscription the school already pays for, shared across more than twenty KEYSTONE apps, and it would have cost the same this month if Monkey Mail had never been built. Charging the whole $100 to this one app would be dishonest. What can be attributed is the share of it this build actually used.

Scroll the table sideways to see every column.

Two ways of prorating the same seat. The usage line is the meaningful one — a subscription is consumed by how much of its allowance you draw, not by how long the laptop is open — and the time line is included because it is the figure people reach for first. They land in much the same place, which is reassuring rather than surprising. Call it two to three dollars of subscription time.

The usage figure rests on one measured number and one estimate, and it is worth being exact about which is which. The second day of the build — both bulk sends, roughly half the commits, the reporting work and this page — was read directly from the account and came to 4% of that week's allowance. The first day fell inside a weekly window that has since reset and can no longer be read, so it is assumed to be of the same order, giving roughly 8% of one week, or about 1.8% of a month.

Role-rate sources: Indeed — Software Engineer, Levels.fyi — Software Engineer, Indeed — Product Manager, Built In — Engineering Manager, Indeed — UX Designer, Glassdoor — Software QA Engineer, Indeed — DevOps Engineer, and the 1.4× fully-loaded-cost multiplier commonly cited from SBA guidance. Hosting: Cloudflare Workers pricing. Claude Team seat pricing and the 5× Premium usage multiplier: claude.com/pricing, checked 19 September 2026; the 4% weekly-allowance figure was read from the account the same day. All figures pulled September 2026; salary data moves, so treat them as directional.

This page is part of the work

It was written in the last sitting on the table above, on the afternoon of the day the newsletter went to every family — which makes it the only part of this build documented while the thing it describes was still warm.

That was deliberate. Most of what is on this page could not have been reconstructed a month later: which question found which defect, what the confusion actually was before it was resolved, how long a sitting ran, the fact that one ended at 00:55 and the next began at 06:06. Written in arrears it would have become the tidy version, in which everything was foreseen and nothing was wrong for long. The defect table in particular only exists because it was written down while it was still slightly embarrassing.

So this is a log as much as an explanation, and it is kept rather than finished. The build figures above — commits, files, lines, tests — are regenerated from the repository every single time this page is deployed, so they describe the app as it stands today and not as it stood when the first version of this page was written. The production figures are refreshed by hand and carry the date they were read. Anything estimated says that it is estimated.

What it runs on

A single Cloudflare Worker, with SQLite for the campaign records, object storage for images, and a cron trigger that drains the send queue a batch at a time and sweeps the mailbox for bounces every five minutes. Sending is Microsoft Graph against the school's own tenancy. The audience comes from App-25 Pupil View over a direct service binding — an in-process call with no URL, unreachable from the internet, which cannot write to Pupil View's data. Monkey Mail holds no copy of the pupil database and has no iSAMS credentials of its own.

Why the school needed this

A school sends a great deal of email to parents, and almost none of it fits what commercial email marketing software is built for. The three options available before Monkey Mail each failed in a different way.

Sending from iSAMS

iSAMS holds every parent and staff address the school has. It is the single source of truth for contacts, and it is correct, because it is the same record the school runs on. It can also send email. But sending a newsletter through it is cumbersome, and it cannot format one. There are no blocks, no story cards, no banner, no phone layout, no brand. A newsletter sent from iSAMS looks like a database sent it.

Email distribution groups

The obvious workaround is to maintain groups in Outlook and send to those. This means building a second contact database alongside the real one and keeping it in step by hand. It starts drifting the moment it is created. A pupil enrols and nobody adds the parents. A family leaves and keeps getting fee notices. Somebody maintains it carefully for a term and then goes on leave. It is not sustainable, and it is not sustainable in the specific way that matters: the failure is silent, and the people affected are parents.

Mailchimp

Mailchimp does the formatting beautifully. It costs money, it holds the school's parent data on its own servers, and — the part that turned out to matter most — it imposes its process on the school rather than supporting the school's. The next section covers that in detail, because the cost is the argument people expect and it is not actually the strongest one.

Monkey Mail against Mailchimp

Mailchimp is a good product. It is a good product for a business sending marketing email to people who chose to receive it. A school sends two quite different kinds of email, and only one of them is that.

Scroll the table sideways to see every column.

Cost, at this school's size

The school has roughly 500 contacts — 344 parent addresses plus staff, growing each intake. Volume is not the constraint; one to four newsletters a month sits comfortably inside any tier's sending allowance. What drives the price is the number of contacts and the number of seats.

Scroll the table sideways to see every column.

Mailchimp prices are the published rates for the 0–500 contact tier, checked on 19 September 2026, and rise once the school passes 500 contacts. The first-year figures reflect the introductory 50% discount; the ongoing figures are list price. Mailchimp offers a 15% discount to nonprofits and charities on request, which is not applied in this table. Overage charges apply if the contact or send limit is exceeded.

The money is real but it is not the decisive argument. Standard at roughly $480 a year is not what stops a school using Mailchimp. What stops it is that the parent contact list would have to be copied out of iSAMS and maintained somewhere else, parent data would sit on a third party's servers, and the school could not send an email that a parent is required to receive.

Sources: Mailchimp — official marketing pricing page, Mailchimp — Why We Require an Unsubscribe Link, and Mailchimp — Add an Unsubscribe Link (the unsubscribe footer is added automatically if the merge tag is absent). Checked 19 September 2026; vendor pricing and tier gating change without much notice, so re-confirm before relying on any single cell.

The two rules everything else was built around

Those two sentences shaped the architecture more than any technical decision did. They are also the reason the send path has never failed: it was the most constrained part of the system from the first hour, and constraints are what get tested.

What it deliberately does not claim

A recurring theme in this build was refusing to report a number that sounds better than the truth.

• Opens are an estimate and say so. The tracking pixel is blocked or pre-fetched by most modern mail systems. The app reports what it can see, labels what it cannot, and never presents an open rate as a fact.
• Human and machine activity are reported separately. In the September newsletter, 248 link clicks were recorded and only 38 of them were people — the rest were a security scanner opening every link in the message within seconds of delivery. A tool that did not separate those would have reported a spectacular click rate that meant nothing.
• "Sent" does not mean "delivered", and the two are reported separately. Microsoft accepting a message means it took responsibility for it, not that it arrived. So the app reads the bounce reports back out of the mailbox and classifies why each one failed — a wrong address that needs correcting in iSAMS is not the same as a full mailbox that does not. It also asks Microsoft directly, through message trace, what happened to each recipient: delivered, failed, still being retried, quarantined, or accepted and then filed as spam. That last one arrives and may never be seen, and until it could be read there was no honest way to report it at all. For the September newsletter the answer was 338 delivered, 5 failed, 1 still retrying, and none filed as spam.
• If bounce detection is not running, the report says so rather than reporting zero bounces as though it had checked.
• Reading time is calculated, not guessed. It says how many words the newsletter contains and how long that takes at a stated words-per-minute rate.

What it does not do yet

Stated plainly, because a page like this is worth less if it only lists strengths.

• Its own contact lists. Audiences currently come from iSAMS and from Entra staff groups. Lists the Marketing team maintains themselves — prospective families, alumni, event attendees — are designed but not built.
• Scheduled sending. Everything is sent by a person pressing Send. Deliberate for now, and likely to stay that way for a while.
• Importing from Word or Canva. Content is written in the editor.
• A formal PDPA review. The app already avoids storing IP addresses and keeps parent data inside the school's systems, but it has not yet been through the school's data-protection process.
• Bounce follow-through reminders. The standing list of problem addresses exists; nothing yet chases anyone to fix them.