How to build a working app against your own data

Who this is for: curious people who aren't developers: event managers, membership managers, anyone with a clear idea and no budget for it. What you'll need: Claude, and API credentials your IT lead will get you. How long: an evening for something working. What you'll have: a real, running app against your real data, and a clear-eyed view of what it would take to make it production.

Why this is suddenly possible

Two things changed at once. AI got good enough to write working code from a plain description, and your membership platform exposes a documented interface that anything can talk to.

That second part is easy to miss. There's no separate internal API and no privileged access reserved for your supplier. The interface MemEx Web and the Member Portal use is the one you can build against. If we can, so can you.

So the constraint on "we should have a small app that does X" is no longer development capacity. It's whether anybody has thought clearly about X.

Step one: pick something small and real

The failure mode is ambition. "An app for members" is not a project you'll finish. "A screen showing tomorrow's delegates that I can search on my phone" is.

• A delegate list for the event you're running this month, searchable, on a phone.
• A screen showing which committee terms expire in the next six months.
• A quick lookup so somebody on reception can check whether a caller is a current member.
• A count of CPD submissions this week, on a wall display.

Notice they all read rather than write. Start there: a read-only thing that shows you data cannot break anything, which means you can be brave with it.

Step two: get credentials, and understand the rule about them

Ask your IT lead for API credentials scoped to what you need, and read-only if you're starting where I suggested.

Then the rule, which is not negotiable: credentials never go inside the app. Not in the code, not in a config file you email yourself, not pasted into a chat. They go in an environment variable or a secrets store, and the app reads them from there.

This isn't box-ticking. An app with a credential baked into it is a credential you can no longer rotate, sitting on a laptop, in a folder somebody will later sync to a personal cloud drive.

Tell Claude this explicitly when you start: "the API credentials must come from environment variables, never hard-coded." It will do the right thing if you ask, and the wrong thing is easy to end up with by accident.

Step three: describe what you want, then keep talking

Don't write a specification. Describe the thing, then react to what comes back. The second and third rounds are where it becomes what you actually wanted.

A starting brief. The last two paragraphs are the ones that keep you safe.

I want a simple web page I can open on my phone that shows
the delegate list for one event from our membership API.

I need to search by surname, and see each person's name,
organisation and ticket type.

Keep it to one page and make it work well on a phone screen.

The API credentials must come from environment variables and
must never appear in the code. It only ever reads - it must
not write anything back.

Here is the API documentation: [paste or attach]

1. Give Claude the API documentation. Paste it, attach it, or point at the reference. It needs to know the real endpoints rather than guess at them.
2. Ask it to explain what it's about to build before it builds it. Thirty seconds that catches a misunderstanding early.
3. Get the smallest version working first: connect, fetch, show a list. No search, no styling.
4. Then add search. Then make it look right. One thing at a time, checking each works.
5. When something breaks, paste the error back and say what you expected. That's the whole debugging loop and it's more effective than trying to understand the error yourself.

Step four: run it, and expect the first attempt to fail

The first connection almost never works, and the reason is almost always one of three things: the credential isn't reaching the app, the endpoint is slightly different from what was assumed, or a permission doesn't cover what's being asked for.

All three produce an unhelpful error. All three are fixed by pasting the error back and asking what it means. You don't need to know. You need to be willing to go round three times.

Ask Claude to run it locally on your own machine first. Not deployed anywhere, not on a server, just running in front of you where you can see it work.

Step five: know exactly what you have built

You have a working prototype. That is genuinely valuable and it is not the same as software.

What it doesn't have, unless you went and did it: anywhere to run other than your laptop, any handling for the API being slow or down, accessibility testing, anyone other than you who can fix it, and any record of how it works.

That's fine. Prototypes are supposed to be missing those things. The mistake is not building one. It's the quiet slide from "I made this useful thing" to "the team now depends on this useful thing" without anybody noticing the transition happened.

The moment to call somebody is when a second person starts using it, or when it stops being something you could shrug about if it broke on a Tuesday. Not before, and definitely not after.

Where the line is, honestly

Read-only things that show you data, for a handful of internal people, are yours. Build them freely. You'll build better ones than a specification would produce, because you know what you want to see.

Anything that writes membership state, calculates money, or that a member sees needs the unglamorous scaffolding: somewhere to test that isn't live, a record of what changed and why, error handling, and cover when you're on holiday. Not because your code is bad, but because those are the things that make software survivable.

The useful part is that you now know the difference from experience rather than being told, which makes you much better at scoping the real thing.

Do this yourself, or have it done

Do it yourself. This is the most valuable afternoon in the whole series, and not mainly because of what you'll build. Somebody who has connected to the API once understands their own platform in a way no amount of documentation delivers, and asks dramatically better questions of everyone who works on it afterwards.

Where we help is turning a prototype into something the organisation can rely on: deploying it somewhere that isn't a laptop, handling the case where the API is slow at renewal peak, making it accessible, and making sure somebody other than you can fix it. That's Maintain and Evolve, and Systems Adoption exists precisely for taking on something that was built by somebody else and now matters.

Bring us the thing you built. Not tidied up, not rewritten first. A rough working app that your team already uses tells us more about what you need in ten minutes than a requirements document does in a month. It has already made every decision that a specification argues about.