Hire a Base44 developer who has actually shipped.

Base44 builds a lot for you, which is exactly why people wonder what they're paying a developer for. The job is everything around the builder: modelling the data properly, setting access rules, wiring in payments and email, making it look designed rather than generated, unsticking the builder AI when it goes round in circles, and knowing the platform's gotchas, like credits, plans, publishing and what search engines actually see.

A good general developer will get there eventually. Someone who knows Base44 gets there on day one.

A demo proves very little. Anyone can make something that looks finished in an afternoon now, which is the whole point of these tools.

Ask for real URLs. Sign up, submit an empty form, refresh halfway through a flow, try it on your phone. Demos rarely survive that. Products do.

Mine are on my work page, and every one of them is live.

This is the question I care about most. In Base44, an entity with no access rules is open to everyone, even people who never signed in. An app can look perfect and still let every customer read every other customer's data.

You don't need to understand their answer in detail. You need to see that the question bores them. If it's boring, they've done it a hundred times. If it's interesting, they haven't. There's a plain-English explainer on row-level security if you want to know what a good answer sounds like.

Get this in writing before anything starts. Some developers build on their own account and hand you a login. Some hand everything over at the end. You want to know exactly what you walk away with if things go wrong.

Then ask what happens after launch: what support looks like and how quickly they'll respond if something breaks. Someone who has shipped a few products will have a ready answer.

My position: we agree who owns what in writing before anything starts, and you get a walkthrough of how it all fits together.

Open every project in their portfolio side by side. If they all share the same gradients, the same frosted cards and the same centred hero with three feature boxes underneath, you're not buying a developer. You're buying a template with your logo on it.

For an internal tool, fine. For the thing your customers judge you by, it matters a lot.

Anyone who says they'd never turn a project down is telling you they need the work more than they need it to go well. You're hiring judgement as well as hands. If they never push back while you're talking about it, they won't push back later either.

I turn things down. Here's who I'm not a fit for, written out so you don't have to ask.

If you want a small internal tool and you've got a bit of patience, build it yourself. The tools really are good enough now, and my free guides exist so you can.

It stops being sensible when the app touches money, customer data or your reputation. Not because the building is hard, but because the failures are quiet: a security gap doesn't show up in the app until someone finds it.