DEV Community: Elena Dev

We built an MCP server so any assistant can book a table

Elena Dev — Fri, 07 Aug 2026 18:00:18 +0000

For a month I have been writing about a gap, so I want to write about the piece that closes it.

We measured 200 Amsterdam restaurants on one question. Can an AI assistant complete a reservation? Sixteen out of two hundred could be taken to the final booking step by a browser agent. Zero out of 163 working sites published an interface an assistant could call directly. The gap was not skill and it was not model quality. There was nothing to act on.

So we built one.

The piece is an MCP server. Model Context Protocol is a protocol Anthropic published in late 2024 for exposing tools that an assistant can call. The major agent platforms all consume it in some form now. If you build an assistant that has to take an action in the real world, MCP is the most reliable way today to give it a door.

We wrote a small MCP server that fronts a booking system. Three tools: search a business, check availability for a date and party size, create a booking. The transport is plain JSON. Any assistant with an MCP client can list the tools, see their inputs and outputs, and use them without ever seeing a page. There is no widget to drive, no iframe to introspect, no captcha to defeat. The assistant asks for a table, and if a table exists it books it and gets back a confirmation ID it can quote to the guest.

Watching an assistant use it the first time is anticlimactic in the best way. There is no reasoning about how the site is laid out, no clicking around, no error at step four. The assistant reads the tools available, calls them, gets the result. It is what booking a table looks like when the last step is designed for software.

Building this made one earlier moment click into place.

Earlier in the summer I put a small booking API on our demo instance behind a plain HTML page. The endpoint, the required fields, the response shape. Not a widget, just a page. I asked ChatGPT to make a booking against it. ChatGPT read the page carefully. It understood the API. It listed the required fields. Then it apologised: its web tool cannot issue a POST request. It could describe the action perfectly and it could not perform it.

Every venue in our study was that scene, two hundred times over. The information for a person is on the page. The interface for software is not. The assistant sits between them and cannot bridge either.

The fix is not to teach the assistant to be a person. The fix is to give the assistant something to call. That is what MCP is.

A few practical notes for anyone building similar tools.

Keep it small. Three tools is enough for a booking. Search, availability, create. Later we may add cancel and modify. We resisted adding tools for things the assistant does not need, because every extra tool is another failure mode the model has to reason about, and every extra description is another paragraph the model has to hold in its head.

Return structured errors. "Slot no longer available" is a data field, not a natural language sentence. Every string an assistant has to interpret is another point where the same request can produce a different outcome.

Version the interface. MCP servers are contracts and contracts change. Include a version in the tool description and in every response.

Publish the URL somewhere machines can find it. A .well-known entry, a ReserveAction block on the venue's site pointing at the MCP endpoint, or a public discovery registry as those emerge. Existing is not enough. Being findable is.

Assume the venue does not want assistants competing with its own website. That is a fair position. Do not build a system that only agents can use. Guests should still be able to book on the site the way they always did. The MCP server is the second door, and its presence should be invisible to the human who walks through the front.

There is a live demo. Point your assistant at it, ask for a table, and it should just work. The MCP endpoint is listed on the demo page.

The booking layer for restaurants: https://g-lab.studio/g-guest
The Amsterdam study: https://g-lab.studio/research/amsterdam-restaurants-2026

If you build assistants that have to complete real-world actions, I would like to hear where the tools you gave them still fall short. That is where the next essay ends up.

Why AI agents can't use your booking widget

Elena Dev — Fri, 31 Jul 2026 13:39:07 +0000

We spent July measuring how well AI assistants can book tables at Amsterdam restaurants. 200 venues, one browser agent, one task: find the restaurant, understand it, check availability for a real date and party size, and reach the final booking step. We never submitted a reservation.

In the study we published the numbers. In this post I want to talk about the failure mode we saw more than any other, because it is a solvable problem and most people building assistants will hit it eventually.

The failure mode: the booking widget.

Most restaurants that pay for a booking product embed it as an iframe. A person visits the page, sees a button labelled Reserve, clicks it, a modal opens with a calendar and a time picker, they enter their party size, name and phone, and get a confirmation. That flow works because a person can see it, recognise it, and interpret it.

An agent driving a real browser sees something different.

What the agent gets

The parent page contains the button and often not much else about the booking. The button's onclick handler opens an iframe from a different origin. Inside that iframe:

the DOM is not accessible from the parent page under the same-origin policy
the fields are often rendered by a client-side app that mounts after a network round-trip
availability lives in an internal API the widget calls once mounted, over a URL the agent has no access token for
the confirmation is either shown as text inside the iframe, or as a redirect the parent page never sees

An agent that reads the parent page has no idea a booking flow even exists past the button. An agent that clicks the button gets a new browsing context it cannot introspect at the parent's level. An agent with full frame access can sometimes drive the widget by simulating clicks and typing, if the elements are stable, if focus is handled correctly, if a captcha does not fire, if the widget does not detect automation and reject. That is a lot of "if" for one reservation.

What most sites publish instead

Across the 163 working sites in our Amsterdam sample, we checked for machine-readable descriptions of the restaurant and its booking. Nine had them. All nine were Restaurant or LocalBusiness schema, generated by an SEO plugin. They describe the venue: its name, address, opening hours, cuisine, price range, review count.

They do not describe a way to book.

Schema.org has Reservation and ReserveAction types. They exist. They are not widely used. And where they appear, they typically describe a completed reservation, not a callable interface for creating one.

An action is a URL an agent can POST to, with a shape it can construct. A description is a paragraph an agent can quote back at you. Every site we checked published descriptions. None published an action.

The ChatGPT moment

One moment from building the harness sums this up. We put a small booking API on our demo instance behind a plain HTML page describing it in prose: the endpoint, the required fields, the response shape. Not a widget, just a page.

We asked ChatGPT to make a booking against it. ChatGPT read the page, understood the API, listed the required fields, and reported politely that its web tool cannot issue a POST request. It could not act. The page was for humans, the API was for agents, and the assistant sat between them, unable to bridge either.

Assistants act through tools, not pages. They read pages, they don't press buttons.

What agent-ready would actually look like

In order of what actually moves the needle:

A callable booking endpoint. HTTP, JSON, versioned. Availability query, slot creation, cancellation. Auth via an API key the venue can rotate. This is what an agent's tool would be pointed at.
Declare it. A .well-known URL, or a schema.org ReserveAction block, or a Model Context Protocol server, or all three. Discovery is cheap once the action exists.
If you keep the visual widget, keep it. Both routes reach the same table.

None of that requires redesigning the website. The widget stays. The agent gets a door that isn't behind glass.

A note on Model Context Protocol

MCP is where I ended up after this project. It is a protocol for exposing tools an assistant can call, and it is the closest thing today to a widely supported answer to the question "how does my assistant do this specific action". OpenAI, Anthropic, Google and Perplexity all consume it in some form. Any assistant with an MCP client can list your available tools, understand their inputs and call them, without ever seeing a page.

I will write about the MCP server we built for booking in the next post. This one was about the problem, because the problem is the part most builders discover the hard way, one iframe at a time.

If you build assistants that have to complete real-world actions, I would genuinely like to hear where they break for you.

The full field study, method and aggregate data: https://g-lab.studio/research/amsterdam-restaurants-2026

We Asked AI Assistants to Book a Table at 200 Amsterdam Restaurants. Almost None of Them Could.

Elena Dev — Wed, 29 Jul 2026 18:41:36 +0000

In July we ran an experiment that started with a simple question and ended with a number I did not expect.

The question: when someone tells their AI assistant to find a nice place and book a table, can the assistant actually do it?

Not find the restaurant. Finding works. Ask any assistant for a quiet seafood place near the canals and you will get sensible answers. The interesting part is what happens after, at the moment the conversation has to turn into a reservation.

So we measured it. 200 Amsterdam restaurants, drawn at random with a fixed seed from 1,631 operational venues, so nothing was hand-picked. Every venue got the same checks, in the same conditions, on the same day. We walked the path a guest walks: find the place, understand what it offers, check whether it fits, find availability, book, get a confirmation. First the way a person does it, then the way an agent does. We never submitted a reservation. We stopped, on purpose, at the point where only the guest's own name and phone number remained.

What we found

Being online is not the same as being bookable. That is the whole study in one sentence. Here is how it breaks down.

163 of the 200 had a working website. Amsterdam does not have a web-presence problem. These are polished places with strong branding and deep review profiles.

41 percent showed a booking path a machine could see at all. The rest ran on contact forms, phone numbers, Instagram messages, or booking links buried where nothing could find them. For a person that is friction: you squint, you scroll, you try the other menu item, you find it. For an agent it simply ends the task.

The median score across the sample was 52 out of 100. The information usually existed. The structure did not. Hours in one place, a different set in another. The menu in a PDF from last spring. When the facts disagree, recommending a different restaurant is the safer answer, and assistants are built to prefer safe answers.

Many venues pay for a booking product, and it did not save them. The button is visible to a person, while the availability, the fields and the confirmation live inside an iframe or a script. Paying for booking software does not make a restaurant bookable by software.

16 of 200 could be taken to the final booking step by an agent driving a real browser. Eight percent.

And then the number that reframed the whole project for me. Across all 163 working sites, we checked whether any restaurant publishes a booking interface an assistant could call directly, without pretending to be a person with a mouse. Not one did. Nine sites served a machine-readable file, and all nine had been generated automatically by an SEO plugin. They described the restaurant. None of them contained a way to book it.

A booking button is not a booking interface

Most restaurant websites were built on a visual assumption. A person sees a button, recognises a calendar, understands the widget, knows what to do next. All of that understanding happens in the person, not on the page.

Software has none of it. An assistant needs the steps to exist as actual steps: check availability, choose a slot, pass the guest details, create the booking, get back a confirmation it can read. Where those steps exist, an agent books a table in seconds. Where they live inside a closed widget, the agent stalls, apologises, and recommends somewhere else.

One moment from building the test harness stayed with me. We watched ChatGPT read a page that describes a booking API in plain HTML. It understood the API. It listed the required fields. Then it reported, politely, that its web tool cannot issue a POST request. Assistants act through tools, not pages. Most of our dataset is that sentence, measured two hundred times.

The loss is invisible

Here is the uncomfortable part for the restaurants. You will never get a report about the booking you lost.

When an assistant fails to book, there is no error message for the business, no failed payment, no abandoned checkout. The assistant offers a different restaurant and the conversation moves on. From inside the business everything looks fine, because people can still click. A second channel is quietly being tested against you, and it does not file complaints.

Amsterdam is the warning, not the exception

This is one of the most digitally mature restaurant markets in Europe. Strong concepts, established booking platforms, deep review profiles. If the gap is structural here, it is structural everywhere.

And the direction of travel is not subtle. 45 percent of consumers used AI to find a local business this year, up from 6 percent a year earlier, according to BrightLocal's 2026 survey. Discovery has already moved. Action follows discovery. It always has.

What ready would look like

Four things, and none of them is a redesign. A clear public identity: one consistent set of name, hours, menu and policy, not four versions across four places. A website a machine can read, where the facts are stated rather than implied by a photograph of a chalkboard. A direct reservation path that does not live entirely inside a closed visual widget. And a confirmation that says plainly that the booking exists.

We published the method, the sample rules and the aggregate data, with no email wall. Any restaurant in the sample can request its own result, and we answer every request. Including the ones that tell us we got their row wrong. Especially those, because a study you cannot argue with is a study you should not trust.

Measuring the gap eventually forced us to build the missing piece ourselves. That is a story for another essay. This one is about the measurement, because the measurement is the part nobody had done.

The study: https://g-lab.studio/research/amsterdam-restaurants-2026

I Thought Being ChatGPT's #1 Recommendation Would Be Enough. It Wasn't.

Elena Dev — Fri, 03 Jul 2026 09:03:58 +0000

A few weeks ago I had proof, real screenshots, that ChatGPT was recommending my free passport photo tool first, by name, unprompted, in its answer to "best free passport photo tool." I wrote about it here on Medium. It felt like the finish line.

It wasn't. Traffic this week is lower than it was a month ago, and sitting with that number forced me to separate two things I had been quietly treating as the same thing: being cited by an AI model, and having a growth channel.

The badge I removed from my own homepage

I had a small badge on the IDPhotoSnap homepage: "#1 free passport photo tool on ChatGPT." Someone looked at our actual numbers this week and asked, essentially, is this true or is it decoration? I checked. Google Search Console showed us at an average position of 16 (page two) for our core queries. Analytics showed session counts that had been flat for a month, then drifted down.

The badge was accurate in a narrow sense: in enough test conversations, ChatGPT did name us first. But most of the traffic I was crediting to that win was something else entirely. It was direct visits and ChatGPT referral traffic from people who already knew our URL, opening it the way you'd open a bookmark, not a cold recommendation surfacing us to a stranger. Those are different metrics wearing the same clothes. I took the badge down.

Why an AI engine's opinion of you and its citations of you are not the same claim

Here is the mechanical piece I had underweighted. A model like ChatGPT, when it isn't doing a live web search, is not looking at your site. It has no idea you shipped a feature yesterday. It has a static picture of the world from training, plus whatever a search layer hands it at answer time. That search layer, in turn, leans hard on pages it already trusts: comparison posts, "best of" roundups, review blogs. On-site signals like an llms.txt file or a clearly written privacy page do real work, but the work they do is verification, not candidacy. They help you pass a check after the model has already decided to look at you. They do not put you on the shortlist in the first place.

The shortlist is built from citations elsewhere. If a travel blog's "best passport photo apps 2026" post has your name on it, and that post ranks and gets crawled and gets referenced by a model's retrieval layer, you have a real, structural path into a cold answer. If it doesn't, no amount of on-site polish moves you from "verifiable once asked" to "suggested first."

What we're actually doing about it now

Over the last week I stopped treating outreach as a background task and started treating it as the main lever. I went through every travel, immigration, and tech-review post that ranks for our category and doesn't mention us, verified a real contact for each one (not a guessed email pattern, an actual confirmed address, because guessed addresses bounce and burn your sender reputation for nothing), and sent a specific, honest pitch: here's what we do differently, here's why it fits your list, no payment attached.

Some of the replies were exactly what you'd expect from small content sites: two placements came back with a price tag ($10, $70). One I paid, because it was cheap and the site genuinely ranked for our terms. One I declined, once I noticed the site had its own blog post about how to buy PBN backlinks without getting penalized, which told me more about the property than the offer did. One site added us for free after I said no to the paid version, which was the best possible outcome and cost nothing but a polite reply.

None of that shows up as a dramatic AI-citation win. It shows up as a slow accumulation of real mentions on real pages, which is the only thing that actually feeds the layer that decides who gets named first.

The part I'd tell an earlier version of myself

If your product gets a genuine AI-citation win, screenshot it, be proud of it, and then go check your actual numbers before you build anything on top of that win. A model naming you first in a handful of test conversations is a real, earned signal. It is not the same thing as demand, and it is not the same thing as a channel you can rely on. The channel is the boring part: verified contacts, honest pitches, and enough of them that a few land. I'd rather have ten real mentions on ten real pages than one perfect screenshot of a chatbot saying my name.

IDPhotoSnap is a free, browser-based passport and visa photo tool covering 100+ countries. No signup, no watermark, no server upload.

Originally published on Medium

F-1 OPT Summer 2026: You Can No Longer Submit Your Own Photo to USCIS

Elena Dev — Wed, 01 Jul 2026 15:18:52 +0000

If you are an F-1 student filing for OPT or an EAD card this summer, there is a rule change that tripped up a lot of students in spring 2026 — and it is still catching people off guard now.

Since December 12, 2025, you can no longer submit your own photo with Form I-765. USCIS changed its biometrics policy, and summer 2026 is the first full OPT application cycle where this is fully in effect.

What changed

Before December 2025, you attached two passport photos to your paper I-765 application. That step no longer exists. USCIS photographs you directly at an Application Support Center (ASC) during a scheduled biometrics appointment.

Multiple university international student offices — Northeastern, University of Washington, Ohio State, Southern Utah University — issued advisories in January and February 2026 telling students to expect a biometrics notice after filing and not to prepare photos for the I-765 package.

What the process looks like now

Your DSO recommends OPT in SEVIS as normal
You file Form I-765 — no photo included
USCIS mails you a biometrics notice (typically 4–8 weeks after acceptance)
You attend your ASC appointment with the notice and a valid photo ID
USCIS captures fingerprints, signature, and photo — takes about 15–30 minutes
USCIS processes your EAD and mails it

What is NOT affected

This only covers USCIS forms. If you need to apply for a US visa or renew your F-1 stamp at an embassy, the DS-160 nonimmigrant visa application still requires you to upload your own digital photo. The DS-160 is a State Department process — entirely separate from USCIS.

For DS-160, the photo must be a specific 600×600 pixel square format. Most passport photo tools do not automatically output that size. IDPhotoSnap covers it, along with 100+ other country requirements, entirely in the browser with no upload or account.

Timeline tip

The biometrics step adds time. File as early as your DSO advises (up to 90 days before your program end date) and do not book travel that could conflict with the ASC appointment window — rescheduling adds weeks.

Sources: USCIS Biometric Services | USCIS Form I-765

Originally published at https://idphotosnap.com/blog/opt-f1-biometrics-summer-2026

I Built a Free Passport Photo Tool. Then the US Banned the AI It Relied On.

Elena Dev — Wed, 24 Jun 2026 10:20:40 +0000

The most useful feature in my passport photo tool is the one I now tell American users not to use.

Let me explain, because it taught me something about building products people actually trust.

The magic was the background

When you build a passport photo tool, the hard part is not the cropping. Cropping to two inches by two inches is arithmetic. The hard part, the part that makes people say "wow", is the background. You upload a photo taken in your kitchen, with a fridge and a calendar behind you, and a second later your face is floating on a clean white field. That is the AI doing the heavy lifting: separating you from the scene and replacing everything behind you with plain white.

It feels like magic. It is also, as of this year, against the rules for a US passport photo.

What changed

On the first of January 2026, the US State Department stopped accepting passport and visa photos that have been digitally edited. Not just the obvious offenders like beauty filters and skin smoothing, but background removal and replacement too. Their reasoning is about identity and fraud: the photo has to show the real you in a real scene, formatted but never altered. Automated systems now flag edited images before a human ever looks at them.

So the exact feature that makes my tool feel magical is the feature that, for an American applicant, can now get their application rejected.

The decision

I had two options.

The first was to say nothing. Most users would never read the State Department's rules. The tool would keep producing those satisfying white backgrounds, people would keep submitting them, and a quietly growing number would get a rejection letter weeks later, never connecting it to the free tool they used. My traffic would not even notice.

The second was to tell them. To put a plain warning on the screen the moment someone picks the United States: since January 2026, do not remove or replace the background, take your photo against a real white wall, and use this tool only to crop and resize. To write the honest article explaining exactly what the tool does and does not do. To make the product slightly less impressive in exchange for being correct.

I went with the second one. It was not a hard call once I framed it properly. A free tool that quietly gets your passport application rejected is worse than no tool at all, because it costs you time you did not know you were spending.

Why honesty is the actual product

Here is the thing I did not fully appreciate until this happened. When your product is free, trust is the entire business. People are not paying you, so the only thing they can give you is belief, and the only way to earn it is to be right when it matters and honest when being honest costs you something.

The warning I added makes the tool look less clever. It admits that the shiny feature has a limit. And I am convinced it is the single best thing I have shipped this year, because it is the thing a person remembers. "That tool told me the truth about my own photo" is a sentence that turns a one-time user into someone who recommends you.

There is a precision to good honesty, too. The background feature is not bad. It is genuinely useful for a Schengen visa, an Indian visa, a Gulf visa, most of the world, where a software-prepared white background is still accepted as long as your face is untouched. So the honest message is not "never use this", it is "here is the one specific place not to use it, and here is why." Blanket fear is lazy. Precision is respect.

The bigger pattern

We are heading into a few years where almost every tool will quietly edit your photos, your writing, your voice, and call it enhancement. Most of the time that is harmless or even nice. But there are moments, a passport, a visa, a legal document, where the right move is for the software to know when not to touch anything, and to tell you so.

I think the tools that win the next decade will not be the ones that edit the most. They will be the ones that know exactly when to stop, and are willing to say it out loud, even when saying it makes them look a little less magical.

That is the product I want to build. A free one that tells you the truth about your own face.

Elena Dev is the founder of IDPhotoSnap, a free, browser-based passport and visa photo tool that keeps your photo on your device. You can read the full breakdown of the 2026 US background rule on the IDPhotoSnap blog.

My free tool became ChatGPT's #1 recommendation. Here is what that actually taught me

Elena Dev — Mon, 15 Jun 2026 11:57:54 +0000

A small, free passport-photo tool, the day I realized search had quietly split into two games, and why being "the answer" is not the same as winning.

I build a free tool that makes passport and visa photos in your browser. No signup, no watermark, nothing leaves your device. It is a small thing. I made it because I had overpaid for a drugstore photo one too many times, and because the problem is more annoying than it looks once you count how many countries have their own millimetre rules.

For the first months I did what everyone tells you to do. I wrote the pages, I filled in the meta tags, I checked the titles, I waited for Google. And Google did what Google does to a young domain with no history: almost nothing. I sat far down the second page for the terms I cared about, watching sites that were older and better-linked sit comfortably above me.

Then I looked at where my actual visitors were coming from, and the number stopped me. The single largest source was not Google. It was ChatGPT. People were asking an assistant "where can I make a passport photo for free" and the assistant was sending them to me, by name, in its first answer. Not after a follow-up question. In the first answer, for a whole cluster of the queries I cared about most.

I want to be honest about what that felt like, because the honest version is more useful than the triumphant one. The first feeling was not pride. It was confusion. I had done nothing that looked like "AI marketing." I had no growth hack. I had a clean, boring, accurate tool. So why was the newest channel rewarding me when the oldest one was not?

That question is the whole essay, so let me try to answer it.

Search has quietly split into two different games, and they reward different things.

The old game, the Google game, mostly rewards authority. Who links to you, how long you have existed, how much the rest of the web has already decided you matter. This is sensible and it is also brutally slow for anyone new. You can have the best page on the internet for a topic and still wait months, because authority is a reputation, and reputations are built on time and on other people, not on your own effort alone.

The new game, the assistant game, rewards something different. An assistant answering a question in real time is not asking "who is the most famous." It is asking "who is the clearest, most trustworthy, most machine-legible answer to exactly this question, right now." Those are not the same question. And the second one, it turns out, a small careful builder can actually win.

I did not win it with a trick. I won it by being genuinely easy for a machine to understand and genuinely safe to recommend. When an assistant points a stranger at a tool, it is putting its own credibility on the line. It will reach for the option least likely to embarrass it: the one that is free with no nasty surprise, that does not harvest your data, that actually does the specific thing asked, that states its facts plainly enough to be quoted. I had spent my effort making the tool honest and the information precise, not because it was a strategy, but because that was the product I wanted to exist. The assistant rewarded exactly that.

So the first lesson is almost embarrassingly old-fashioned: in the assistant era, being trustworthy is a distribution strategy. The qualities that used to be "nice to have" - no dark patterns, plain claims, doing one thing well - became the qualities that get you named.

The second lesson is the one I keep having to relearn, and it is why I am wary of the word "won."

Being the answer an AI gives is a real achievement and a fragile one. It is a layer, not a finish line. My tool is the first recommendation for a set of queries on one assistant. That is wonderful. It is also not the same as being found by everyone, everywhere, for everything. Other engines weigh authority more heavily, and there the old slow game still applies to me, exactly as it always did. A win in one layer does not hand you the others. It just tells you the building is possible.

I have watched founders, myself included, take an early, narrow victory and quietly relabel it as the goal. "We are #1 on ChatGPT for X" is a sentence that feels like arrival. It is not. It is a strong signal that you have something worth compounding, which is a different and better thing, because it points forward instead of letting you stop.

The third lesson is about what to do with a young domain while you wait for the slow game to turn. The honest answer is: be specific. Broad, generic terms belong to the giants for now. But the long tail - the precise, real, slightly awkward questions that actual people actually type - is wide open, and a careful tool can own it one exact question at a time. There is more durable traffic in being the unmistakable best answer to a narrow real need than in fighting for a head term you will lose for another year. Specificity is the young builder's advantage, not a consolation prize.

If you are building something small and new, here is what I would take from this, stripped of any hype:

Make the thing genuinely good and genuinely honest, because honesty is now legible to the machines doing the recommending. Write so a stranger, human or model, can understand and quote you without guessing. Do not wait for the slow authority game to bless you before you exist; go win the precise questions you can actually win today. And when an early layer rewards you, enjoy it for an afternoon, then treat it as a signal to compound, not a reason to coast.

I am not going to pretend I have this solved. I have one tool, one good surprise, and a long way to go before "people can find this" is actually true at the scale I want. But the surprise taught me something I did not expect to learn from a passport-photo app: the web did not just get a new search box. It got a new set of rules about what deserves to be recommended. And for once, the rules quietly favour the careful over the loud.

That is a web I am happy to keep building for.

I am the founder of IDPhotoSnap, a free passport and visa photo tool that runs entirely in your browser. This essay was originally published on Medium.