Shipping 20+ apps for real clients has taught me that the code is rarely the hard part. The hard part is working out what someone actually needs, because the first thing they ask for is rarely the whole story.
I'm AJ. I'm 15, I'm a Base44 Partner in Belfast, and I've been freelancing for the past year. Real products for real clients, with sign-ins, Stripe payments and Resend email.
- apps shipped for real clients
- 20+
- industries, including legal tech, real estate, roofing and logistics
- 8
- from 9 reviews on my Base44 Partner profile
- 5.0
None of what follows came from a tutorial. Most of it came from getting something wrong, then working out why.
The first ask is rarely the real problem
Say someone messages me asking for a button. Fine. But why do they need it? Who presses it? What happens after they do?
Often the button is a symptom. The real problem sits upstream, like data in the wrong shape or a flow that makes people do the same thing twice. Build the button without asking and you've shipped a very polished plaster.
So before I build anything, I ask the same questions every time. What's the real problem? Who's it for? What does done look like?
It sounds slow. It isn't. Asking is quicker than building the wrong thing twice, and clients notice:
He not only helped resolve my issues but he has a great way of thinking through the process.
If you take one idea from this post, take this one. Your job is to find the problem underneath the ask.
Plan it properly, or pay for it later
My planning is boring on purpose: the data, the access rules, the screens and the order to build them in. I learned that by getting it wrong a few times. (Screens built before the data model tend to get rebuilt once the data model shows up.)
The best proof I have is Hattle, my World Cup sweepstake app. I sketched the whole system on paper before I touched a keyboard: the draw, the scoring, the money tab and how debts would settle between people. Then I built it in one eight-hour stretch.
"8 hours" sounds rushed. It wasn't. The thinking was done on paper, so the build was mostly typing.
Fast because it was planned
- The decisions happen on paper, where they're cheap
- The build is mostly typing
- Still holds up three months later
Fast because corners got cut
- Screens built before the data model
- Screens rebuilt once the data model shows up
- Looks fine on day one, then breaks
You can't always see the difference on day one. You can three months later.
Security is your job, not the platform's
This one scares me a bit, because it's so easy to miss.
Base44 handles a lot of security for you, and its security docs (opens in a new tab) are honest about where that stops: "You are responsible for your app's security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish."
So access rules go in when the data does, not in a panic the week before launch. Every entity gets row-level security, and the security scan runs before anything goes live.
When I review someone else's app, I check who can create, read, update and delete every kind of record. Then I try to read other people's data from a test account. The patterns I use are in how to lock down a Base44 app before launch.
It's also the bit clients notice least, until it goes wrong. So I was chuffed when a review called it out by name:
AJ is the real deal, from Front End UI, Pen Testing, Complex API integrations. AJ really knows what he's doing. 100% recommend working with AJ on your next project!
The boring checks are where apps break
Empty states. Error messages. A real phone. A keyboard with no mouse. The security scan. What search engines actually receive.
Nobody asks for any of that. It's also where apps break, so I check it before your users find it for you.
The search engine one caught me out on my own site. Some URLs were handing crawlers a plain app shell instead of the real page, and the page looked perfect in my browser the whole time. That's the story in why Google sees an empty page on your Base44 app.
One of my shortest reviews is one of my favourites, and SEO is right there in it: "He setup payments, fixed my SEO, and cleaned up my site! great to work with, really good communication!" That's Connor, in a Base44 review.
Say it straight, even when it's a two-minute fix
If it's a two-minute fix, I tell people the fix. If a project needs a stack I don't know well, I say so up front rather than take the work and figure it out later.
That can feel like leaving money on the table. I don't mind. Trust is worth more than one job, and people remember who was straight with them.
Doesn't look to sell me his services unless I need them and was ready to help for free because it was a 2 minute fix.
Same goes for saying no. I'm probably not a fit if you need it live tomorrow and don't mind how it gets there. Better to say that now than halfway through.
Helping in public is how at least one client found me
That same review opens with "Found AJ on Discord".
I didn't plan that as marketing. I was in the Base44 Discord answering questions, because you learn a platform fast when you answer questions about it every day. It's also the quickest way to find your own gaps. Niko Lee's review put it this way: "There are days where it feels like AJ is answering half the community himself."
I also keep an unofficial, community-made archive of Base44 Office Hours, with every session up to #70 recapped and searchable. Same idea. Useful stuff, in public.
If you're young and wondering where clients come from, that's my honest answer. At least one of mine came from being useful where people could see it.
Build for the users, not the screenshot
A client pays me. Their users decide whether the app works.
If something in a brief will confuse the people using it, I say so, even when it's the client's favourite bit. That conversation is awkward for about thirty seconds. Shipping something confusing is awkward for months. Megan's review picked up on exactly that: "He doesn't put you in mind just as a client, he puts your users in mind..."
Design is part of this too. A lot of AI-built apps look identical because nobody overrode the defaults, and users can tell. I went into that in why AI-built apps all look the same.
Hand it over so they don't need you
Every build ends with a walkthrough and notes, so the client understands what they own and is never stuck waiting on me.
It feels backwards to make yourself replaceable. Weirdly, people come back anyway. Mitch again: "After that I worked with him a number of times to help me when I get stuck with my app." Nobody's locked in. That's the only kind of repeat work I want.
What about being 15?
It comes up. Fair enough.
My honest answer is: judge the work. The reviews are word for word from my Base44 Partner profile, and I'd rather they do the talking.
One reviewer wrote "His experience at his age is admirable", which I'll happily take.
Age cuts both ways, though. I've had less time to pick up bad habits, and a lot more to learn. So I ask more questions than feels polite, and I double-check the unglamorous stuff. Both of those help at any age.
My checklist before any client build
Say the real problem
In one sentence. If I can't, I'm not ready to build.
Know who it's for
Who uses it, and what "done" means to the client.
Plan the data first
Entities and access rules before any screens.
Lock it down
Row-level security on every entity, and the security scan has run.
Do the boring checks
Empty states, error messages, a phone and a keyboard all work.
Check what search engines get
Not what my browser shows. What a crawler actually receives.
Hand it over
A walkthrough and written notes, so nobody's stuck waiting on me.
FAQ
Can a 15-year-old build apps for real clients?
Yes. I've shipped 20+ apps for real clients across 8 industries, and I'm a Base44 Partner with a 5.0 rating from 9 reviews. Age matters much less than asking good questions and checking the boring details before launch.
How do young developers find freelance clients?
At least one of my clients found me in the Base44 Discord, where I spent a lot of time answering other builders' questions. Being useful in public builds trust before anyone hires you. It also teaches you the platform fast.
Is a Base44 app secure by default?
Not completely. Base44 handles platform security, but its docs say you are responsible for your app's security settings. Add row-level security to every entity and run the security scan before you publish.
What's the most important lesson from freelancing?
The first thing a client asks for is rarely the real problem. Ask what the problem is, who it's for and what done looks like before you build anything. It's quicker than building the wrong thing twice.
Got something that needs building properly, or a young builder with questions of your own? Email me at hello@aatmanjain.com. I read every message myself.




