Designed a mobile app myself using a free tool — hand it over to an agency or build from scratch?

Code exported by free no-code/design tools is almost always pure spaghetti; bloated with redundant dependencies and a massive memory hog. If the app crashes at 5 AM when kitchen managers are trying to rush an order in, you'll lose clients instantly. Let them use your design as visual reference, but demand clean custom code.

When reviewing contracts, mandate these three items: 1) Full ownership of the source code transfers to your business on day one, 2) Apple and Google store review submissions are included in the scope of delivery, 3) At least three months of free post-launch bug fixing must be provided.

You'll truly appreciate that 40,000 SAR agency quote the second that 12,000 SAR freelancer stops answering your calls two months in. Cheap dev work is always paid for at least twice.

Take screenshots of every single screen in your prototype and compile the full user flow into a PDF. Hand that over as your formal technical specification when requesting quotes. That cuts off their ability to invent out-of-scope surcharges right from the jump.

We had a similar B2B logistics app built from scratch in Jeddah. Because we handed them a complete interactive prototype upfront, the agency dropped their bid from 55,000 SAR down to 34,000 SAR since their analysis phase was basically cut in half. Your prototype is serious bargaining power.

Under Saudi Ministry of Commerce regulations, ownership of the source code must be explicitly stated in software contracts. Otherwise, the code can be considered the agency's intellectual property. Whichever quote you go with, make sure the contract states that code repository access will be granted in your company's name.

Do restaurants actually need a mobile app? Wouldn't a mobile-friendly web dashboard do the trick for notifications and invoicing to begin with? Have you factored in app store commissions and annual developer account fees?

Good call starting this thread. Taking notes for two weeks yields better results than a six-month estimate.

If I were you, I'd go this route.

I didnt know that.

I agree, and I'd like to emphasize that. Payment schedules should be tied to project phases, not calendar dates.

The real issue isn't the number, but what it's based on. Just leaving this note, it might be useful.

i'm curoius too.

Saved. Solutions that work at a small scale collapse when you grow; I learned this late.

There's one point I'm curious about. If you don't write this down from the start it leads to arguments later.

If acceptance criteria aren't written, when the work is done is open to debate. Good luck with that.

I agree with this. Code without setup documentation isn't yours, even if you have it.

Good call starting this thread.

I'd say don't rush. anyway implementing a change request process doesn't slow things down it speeds them up.

I'm also curious if anyone does it differently.

Let me summarize the topic, since several different answers were given. Weekly written progress reports are much more useful than asking for dates.

If you have questions, write them; I'll answer as best I can.

How did you solve this? Implementing a change request process doesn't slow things down it speeds them up.

The harder it is to reverse a decision, the slower you should make it. Hope this helps.