Okay, But Actually… Owning an App Doesn't Mean Maintaining It Alone
Pedro said his membership platform costs him around $50 a month to run. Someone replied that custom software leaves the client alone after launch. That's nonsense. The $50 is what Pedro pays to run his platform. It tells us nothing about the support he'd provide a client.
Say a studio runs its classes through a custom app. A member pays, but the booking doesn't appear. She arrives with the receipt on her phone and expects a place in the class.
The person at reception can let her in. After that, somebody needs to find out why the booking failed and fix it. If I'm supporting the app, the studio calls me. Some businesses have their own developer. The studio should know who gets the call before a customer turns up with a receipt and no booking.
Agree on help before launch
Talk about support before launch. A business taking paid bookings every day may want regular checks and a quick response when payments fail. Another business may be happy to call when it needs a change.
A promise to look at non-urgent bugs within a few days is different from being reachable when bookings stop the night before a full day of classes. The studio may also want a simple fallback for staff, such as checking a receipt and adding the member to the class list by hand. They can choose what help is worth paying for once they know what happens without it.
The agreement should also say what counts as fixing a fault. If the app was supposed to create a booking after payment and didn't, that's a fault. If the studio now wants a waitlist, that's new work. Mixing the two under “support” without talking about cost is a lovely way to start an argument later.
There are less exciting jobs in the background. Backups need checking, and changes to a service the app uses can require updates. If an account has to be removed, the business needs to know who can do that. The UK government's guide to running live services includes monitoring and fixing problems after launch. The day an app goes live does not finish the job.
The accounts belong to the client
In my projects, the client owns the accounts for the services running the app, including hosting and the database. I can have the access I need to work on it. The client doesn't need to borrow my login to reach their own records.
Owning those accounts lets the client call me back for a new feature or give another developer access. That developer will need time to learn the app, but they should be able to see where the code lives and get access to the services it uses. The first week should not be spent finding out which former contractor's email address owns the database.
A handover doesn't have to teach the owner to program. Give them the information they'd need to bring in help: where the app runs, who controls the accounts, how to report a fault and how to recover important records.
Yes, I cite the National Cyber Security Centre a lot. It's the UK's government cyber security agency, and its small-business guides are actually readable. Its backup guide says to identify the systems you depend on and test that you can restore your records. I work with clients outside the UK; I'd give them the same advice.
A client can own all of that and still pay me to maintain the app. If they prefer help only when they need it, we can arrange that too. Owning the accounts doesn't appoint the client as the new developer.
If the studio buys a booking tool instead
With a subscription, the vendor handles updates to the shared product. It won't necessarily sort out every problem a business has with its own setup, staff accounts and connected services. The NCSC's guidance on using SaaS says businesses still need to manage access, review connections to other services and plan for incidents.
Many businesses also pay someone to build their setup inside that subscription: booking calendars, payment steps, automated messages. If the studio hires a specialist to set those up and the member's paid booking goes missing, it can contact the software vendor. But if the platform is working and the studio's setup is the problem, who fixes that? The specialist might, if support was part of the deal. Otherwise the studio is back to finding someone who understands what was built. Meanwhile, the member still needs a place in class.
It's funny how everyone suddenly remembers post-launch support matters when the words “custom software” appear. A consultant can spend weeks building a business's workflows inside a subscription, leave, and take their knowledge of the setup with them. Apparently that is normal. Write some custom code and people begin planning the client's abandonment before the proposal has even been sent.
And no, the business owner cannot necessarily fix the SaaS setup themselves because it uses boxes and menus instead of code. Have you seen some of these platforms? A workflow with branches, tags, triggers and fifteen automations is still complicated. Giving it bright colours and a drag-and-drop editor does not make the business owner responsible for understanding it. They have their own job.
If the person who built that setup disappears, the business may need another specialist to untangle it. That is the exact problem custom software was accused of having, except now there is also a monthly subscription.
Before hiring anyone, ask what happens after launch. If the answer is “good luck,” keep looking. The same trap exists inside SaaS; it just comes with a monthly invoice.