Hiring someone to build your app or website is hard to judge if you are not technical. Portfolios look polished, everyone says they are fast and reliable, and quotes are difficult to compare. The best tool you have is a set of good questions, and attention to how they are answered.
These are the questions I would ask if I were hiring a developer, and what a good answer sounds like. They apply whether you are talking to a freelancer, a studio or an agency. If you are still deciding between those, start with freelance developer or agency.
About their past work
"Can you show me live apps or websites you built?" Live means downloadable from the stores or open in a browser now, not only screenshots. Install the app. Click through the site on your phone. Is it fast? Does it feel solid?
"What exactly was your role on each one?" "I built the mobile app, the backend and the admin, and I run the servers" is a specific answer. "We worked on it" is not. Many people show projects where they did a small part.
"Is it still running, and do you still maintain it?" Products that are maintained by the same developer years later say a lot about reliability and relationships.
"Have you built something similar to what I need?" Not identical, but similar in the hard parts. If your project is a booking app, ask about availability logic and notifications. If it is a field app, ask about offline use and photos.
About their process
"What happens in the first two weeks?" A good answer involves understanding your business, clarifying the scope, and producing something you can review: a written scope, flows or wireframes. A developer who wants to start coding on day one without that is guessing.
"How will I see progress?" Look for regular working builds: the app on your phone through TestFlight or a test track, or a staging website. Weekly or fortnightly demos are a good sign. Status reports without anything to try are a warning sign.
"How do you handle changes to the scope?" Scope always changes a little. A good developer has a clear, calm way to handle it: assess the impact, agree on it in writing, adjust the plan.
"Who will I talk to, and how quickly do you respond?" You want direct access to someone who understands the technical side, and a realistic response time.
About ownership
"Who owns the code, and where is it stored?" The answer should be: you own it, in a repository under your account or organization, with the developer given access.
"Whose name are the app store accounts, domain and hosting in?" Yours. If a developer resists this, walk away. It is the single biggest protection you have if the relationship ends.
"What do I get at the end?" Source code, access to all accounts and services, and documentation on how to build, deploy and run the system.
About quality
"How do you test?" Listen for specifics: testing on real devices, including older Android phones, automated tests on critical logic, a beta period with real users. "I test everything" is not an answer.
"How do you handle security?" For any product with logins or personal data: password handling, permissions enforced on the server, HTTPS everywhere, secrets kept out of the code, regular updates. Ask how they would handle a vulnerability found after launch.
"What happens if the app crashes for a user?" Good developers set up crash reporting and error tracking so they find out before users complain.
About hosting and operations
"Where will it be hosted, and why?" The reasoning matters more than the provider. For simple websites, managed hosting. For applications, a server or platform with backups and monitoring. See hosting a business website.
"How are backups done, and have you tested restoring one?" A confident, specific answer here is rare and valuable.
"How do you deploy updates?" Look for an automated pipeline rather than files copied by hand. My own projects ship through CI/CD pipelines, which makes updates routine and reversible.
About local and regional needs
"Have you built bilingual Arabic and English products?" Right-to-left support done properly takes experience. Ask to see an example in Arabic.
"How does the app behave on a weak connection?" Wherever users are on mobile data, this is a real requirement. The answer should go beyond "it will show an error".
"How will customers pay?" A developer who knows the local market will ask how your customers pay today and design around it, rather than assume card payments.
About after launch
"What maintenance will this need, and what do you offer?" Honest answers mention OS updates, store requirements, dependency updates, server care and bug fixes. See app maintenance after launch.
"If you were unavailable, could another developer take over?" With documentation, access in your name and a standard stack, yes. That is the answer you want.
About cost
"What is included in this quote, and what is not?" Check for the admin side, the backend, store publishing, hosting setup and post-launch support.
"How do payments work?" Milestones tied to deliverables you can see are healthy. Large upfront payments with nothing to show for weeks are risky.
How to use these questions
You do not need to ask all of them in one meeting. Pick the ones that matter most for your project, send a few in writing beforehand, and keep the rest for the call. Pay attention to how the answers come back, not only what they say. A developer who answers clearly, admits what they have not done before and follows up with questions of their own is usually the one who will communicate well during the project too. Take notes and compare candidates on the same questions, so the decision is not based only on who was most confident.
Red flags in the answers
- Exact prices before understanding your project.
- Vague answers about their role in past projects.
- Reluctance to put accounts in your name.
- "We can do anything" with no questions about your business.
- No mention of testing, security or maintenance.
- Pressure to decide quickly.
Green flags
- They ask more questions than you do.
- They suggest leaving features out of the first version.
- They explain trade-offs in plain language.
- They are clear about what they do not do.
Before your first meeting, it helps to prepare a short description of your project. See how to write an app or website brief for a template.
I am happy to answer every one of these questions about my own work. Have a look at my projects, read about me, and get in touch.