The Stripe Notifications That Proved She Could Build An App Without Coding

Ellen Britt was standing in her kitchen when her phone started going off. Bing, bing, bing, bing.

"I thought, ' What the heck?" she told me. "So I go and look at my text. Stripe, Stripe, Stripe, Stripe, Stripe."

Her homeopathic mentor had published an article on Substack the night before, along with an hour-long video tour of the thing Ellen had built. And Ellen hadn't planned a launch or built a list to announce one to - just about a hundred Substack subscribers and a circle of colleagues she figured would "probably support poor Ellen's little microbusiness here."

Instead, people couldn't get over there fast enough to buy it.

Ellen is the clearest proof I've seen this year that you can build an app without coding and actually sell it. Not a prototype or a demo, but a working web app with paying subscribers, built by a woman whose professional background is emergency medicine and homeopathy.

I've been wanting to talk to her for a while. We've been circling each other in the same online business world for years- mutual friends, the whole thing- and when I saw she was building, I knew I had to get her on. This is my favorite kind of conversation right now: a woman who decided she was going to make something, and then made it.

(The full interview is up on YouTube and Substack. This is the written version, with the parts I keep coming back to.)

Who is Ellen Britt?

Ellen Britt is a former emergency medicine physician assistant turned homeopath who, in about nine months, taught herself to build and sell web applications using AI. She has no coding background.

The longer version: more than twenty years as a PA in emergency medicine, then internet marketing and telesummit production and all of that, until a personal healing experience with homeopathy sent her back to school at what she calls "a late date" to become a homeopath. She also has a doctorate in biology, and her dissertation was on the American kestrel, which meant many, many weeks banding falcons in the cornfields of Indiana.

So she's not a developer, and not adjacent to one either... just a woman with an enormous range of interests and no coding background at all.

What she did have was the thing I keep seeing in the women who end up building something. She got jealous.

"I kept seeing all these guys basically on X," she said, "and they just kept saying, well, just build something. Just build something. And I think, well, how can I build something? I'm not a coder."

She looked at the platforms, Lovable and Bolt and all of them, and then she looked at her existing pile of subscriptions and thought, do I really want to spend more money? So she asked ChatGPT about it, and ChatGPT said the thing that changed the next nine months of her life.

You know, Ellen, you don't have to do it that way.

She said, oh really? Tell me more. And it explained that it could help her plan the app, Claude could write the code, and she didn't need to rent a platform to do any of it.

"I said, let's go. So we did."

Why did she abandon her first app?

Because it wasn't different enough, and she figured that out fast instead of marketing her way around it.

Her first build was a homeopathic materia medica... a reference compendium, with flip cards and hover effects and all the nice touches. She built the whole thing, and then she walked away from it.

"It became apparent to me very quickly that homeopaths didn't need another materia medica thing, and a lot of people were doing it. There's nothing special about this."

She didn't sink cost into it. She noticed it was a solved problem and moved on, which is a skill, and a business skill at that, not a technical one.

The Easy-Bake Oven moment

Here's where it gets interesting. Ellen belongs to a group of homeopaths who, in her words, "like to color outside the lines," and they kept talking about radionics... machine-made remedies broadcast to clients over a distance. Which Ellen thought was "the biggest bunch of hoo-ha I had ever heard."

But people she respected kept reporting results, and she couldn't experiment herself because she didn't have the machine. (Her word for what she felt about that: "insanely jealous.") So she finally got her hands on one, a Vitalus, made in England, one of the best-known instruments in that world, and took it out of the box.

"I thought, thank God, this thing's like an Easy-Bake Oven. Light as a feather. It's got these little dials. And I thought... huh."

That huh is where the app came from.

She started talking it through with Claude and ChatGPT, found piles of old radionics documents, compiled them, uploaded them, and the three of them went back and forth for a couple of months about whether this could even work. She got a prototype in front of her mentor, who tested it and said, "Oh, it works." Then five or six colleagues beta-tested it into the ground for three and a half months, and when they were finally done, her mentor said she was going to write an article about it.

Which is how Ellen ended up standing in her kitchen with her phone going "bing, bing, bing."

Is a niche ever too small to build for?

Ellen's answer is no, and hers is the best evidence I've got. Her market is homeopaths who practice radionics. It sold anyway.

She said it better than I would have:

"This is an extremely narrow niche. This is so niched down it's almost microscopic. So that should encourage people, don't be afraid to do that, because I'm solving a particular problem."

And the problem is beautifully specific, because her customers own a physical machine that does not travel. So one of them is sitting in an ICU waiting room next to a parent and cannot exactly set up a piece of equipment in the corner of the room, or she's getting on a plane to visit family and is not packing the thing.

Now she takes out her phone instead, and that's the whole wedge. The app isn't better than the machine; it's with you, and that turned out to be worth paying for.

If you've been sitting on an idea because the audience feels too small... read her niche again.

What tech stack did she use to build an app without coding?

VS Code on her own machine, with Claude writing the code; GitHub for the repo; Netlify for hosting; and Stripe doing double duty as both payments and customer database. No Supabase. No platform subscription.

Here's the sequence she actually followed:

1. Build locally in VS Code. Everything runs in a browser on her own computer, where nothing she tries can break anything live.

2. Push to GitHub. The repo is hers, and the code stays on her machine and is backed up.

3. Deploy through Netlify. GitHub hooks to Netlify, which picks up changes and deploys them. She also uses Netlify Blobs.

4. Let Stripe be the database. The only thing being stored is customer information, and that already lives in Stripe.

5. Export to MailerLite when she wants to email. Customer emails come out of Stripe and into her list.

I stopped her at step four, because I had assumed she'd need a database. "Claude said, you know, we don't really need Supabase. You can just use Stripe." One fewer service, one fewer bill, one fewer thing to maintain.

A few more details worth stealing:

• Magic link instead of passwords. The app lives on a subdomain behind a magic link gate, which Claude suggested. (Ellen calls Claude "he," which I found delightful.) No password reset flow, and no support tickets about forgotten logins.

• The website has no blog. thetwistedtensor.com pulls her three most recent Substack posts in through RSS and updates itself, so she writes in one place and the site reflects it.

• There is no dashboard. When she wants to change the site, she tells Claude what she wants, Claude hands her a command, she pastes it into the terminal, and the site changes. "I just control everything through the terminal. It's so easy."

She had Manus build the marketing site, which brings us to the part everyone should tattoo somewhere.

Why does owning your own code matter?

Because platforms disappear, and when they do, the people who own their repo shrug while everyone else scrambles.

When Manus started unwinding, users got what Ellen described as a screaming email: get your data off Manus.

"I said, well, it doesn't matter to me. I've got my data off Manus, and I have the code. I don't have to worry."

But plenty of people had hosted their websites on the very thing that built them, and they didn't know how to get the code out or what to do with it if they did. Then the platform is gone and they're scrambling.

I've been saying a version of this for a while, and Ellen just lived the proof: build the asset, then own the asset. Platforms are fine as a starting point, and Lovable, Bolt, and Base44 get people building who otherwise would never start, which matters. But there's a difference between a place you learn and a place you live.

I'm not interested in going back to renting.

Should you one-shot a prompt or go back and forth?

Go back and forth. A one-shot prompt hands your tech stack decisions to the model, and you find out what it chose weeks later when you want to change something.

Ellen got into the short window when Fable was available on the Claude subscription, and she had her prompts ready, so in one evening she got two apps out of it. Which sounds like a win, and mostly it was, right up until she looked at what she'd actually been handed.

"What I didn't realize was that Fable had architected Supabase and everything into the stack all the way through it. I didn't even go back and forth. It was a one-shot prompt. Boom, here's your app. So I didn't have any say-so in the tech stack."

When she wanted to change it later, Claude told her she'd essentially be starting over, and she said no thanks. Her takeaway is the single most practical thing in the whole conversation:

"It's better to go back and forth with Claude rather than to try to one-shot a prompt. If I do another app, I'm going to have total control over the tech stack."

The conversation is the product decision. When you skip it, someone else makes those decisions for you.

How did she price it?

Seven dollars a month, seventy a year, with a $47 one-time add-on sitting locked inside the app itself.

Ellen started where I always start, adding up the hours in her head and spiraling about what it's worth, and then she landed somewhere completely different. She's calling it a founder's price without committing to how long it stays.

Inside the app there are more than eleven thousand remedy rates in the library, plus a locked tab of specialized protocols her mentor insisted she charge separately for. It sits right there in the product, visible and locked, which makes it a quiet little advertisement for itself, and the welcome email mentions it and tells people to email her for details.

Her reported split: roughly half monthly, half annual, and a large majority of the annual buyers took the upsell. (Ellen's numbers from the interview.) Then customers started emailing to ask what else she had coming, which is the part I love. She trained them in the first thirty days to expect add-ons, and they showed up asking for the next one.

The distribution model she stumbled into

She didn't plan this one at all. Her customers are practitioners, and practitioners started telling their clients to buy a subscription, because a practitioner can set up a schedule, export a file, and email it to a client who then runs it herself. So professionals are customers, and their clients become customers.

"I stumbled into it," she said. "I did not know that that was going to happen."

You find things like this by shipping and watching, not by planning, which is more or less what Dheeraj Sharma told me a while back: just get people in and using it before you worry about marketing it.

What about customer support?

Ellen pastes the customer's question into Claude, Claude looks at the code and tells her whether it's user error or a real bug, and then writes either the reply or the fix. Usually in five minutes.

The fear I hear most from women thinking about building software is not the building. It's the aftermath. If I sell this thing, am I now a help desk?

Her system is almost embarrassingly simple. Claude looks at the code, sometimes asks her to run a command in the terminal so it can see the relevant lines, and then tells her which of two situations she's in: either the customer is doing something wrong, and here's the email to send her, or it's a real gap, and do you want to fix it now? Then she goes back to the customer and says thank you, you surfaced a real bug, it's fixed, refresh your screen.

"So Claude becomes my customer support."

The other thing she did, which I don't think she gives herself enough credit for, is personally email every single customer at the start. No automated sequence, just her, going back and forth with the first cohort, learning them. I don't expect that from a company anymore, and I notice every single time it happens... too many of them could kill it if they just gave a damn about their customers.

What you can actually steal from this

Ask before you build. Ellen doesn't pay for a database because she asked whether she needed one. Have the tech stack conversation before you have the code.

Build locally first. Everything on your own machine, in your own browser, where you can break things freely, and push when it works rather than while you're still figuring out whether it works.

Let the first one be wrong. She built a whole materia medica app and walked away from it because it wasn't differentiated. That's not a failure, that's calibration.

Go smaller than feels reasonable. The narrower the problem, the more obvious the purchase.

Price for conversation, not for your ego. Seven dollars got her dozens of engaged users and a Telegram group full of feedback in the first month, where a $2,000 product would have gotten her silence.

Put the upsell in the product. A locked tab is a better sales page than a sales page.

Own the code and the data. Repo in your hands, hosting somewhere you chose, customer records somewhere you control, because platforms disappear.

Use AI as your support desk. Paste the ticket, look at the code, fix or explain, move on.

Talk to the first hundred people yourself. All of them, by hand, because you will never get that window back.

What if you're not where Ellen is?

What if you've never opened VS Code? Start where Ellen started: a Udemy Python course she never finished. She quit it once she realized she didn't need to learn to code, but she'd already gotten comfortable in the editor. That was the whole point of the exercise, and it took her a few evenings.

What if the terminal genuinely scares you? Then start on Lovable or Bolt or Base44 and graduate later. Ellen's own words: "you have to meet people where they are." Just go in knowing you'll want to move off it eventually, and don't host your live business on the thing that built it.

What if you don't have an audience to launch to? Ellen didn't either. Roughly a hundred Substack subscribers and no list. What she had was one person with credibility in her niche who was willing to write about it. One trusted voice in a small pond beat a big list.

What if you already have an offer and a business? Then you're looking for the thing your clients keep asking you for that you keep doing manually. Ellen's second act here is a skill that writes her detailed new-client onboarding email, complete with a database of remedies and links, triggered just by typing "I have a new client."

The thing underneath all of it

Ellen has been building for about nine months. In that time: the radionics app that's selling, an intermittent fasting app for women 45+ that she's building with Denise Wagner, an intention app called One Scalar that a small group in Colorado is currently using once a week to intend for rain, and a spin-off from that called Kalmer that's built and sitting on the runway. She's also converting the three custom GPTs she and Denise used to run their build cohorts (Claire scopes the idea, Isabelle writes the prompt, Nova helps you deploy) into skills.

She didn't set out to build an ecosystem. "I didn't do it purposefully. I just went with my interests."

At one point in our conversation, she said the motivation was never the money. It was: can I do this, and will it work?

That's what I keep coming back to, and it isn't the Stripe notifications, fun as those are. It's the part where a woman with a doctorate in falcons decides she's curious and follows it all the way to a business. Ellen and I both know what it's like to look up and realize it's 3 a.m. and you don't want to go to bed because you just had another idea.

Midlife is the biggest gift women get. This is my do-not-give-an-F era, and it turns out that's an excellent operating condition for learning to build an app without coding.

If your version of "huh" has been sitting in the back of your head for a while... go poke at it this weekend.

Find Ellen at thetwistedtensor.com, on her Substack From The Field, or email her directly at ellen@thetwistedtensor.com.

She's a good old Southern gal, and she might just call you.

Watch or listen to the full conversation above. And if you build something because of it, I want to hear about it.