CI/CD, Servers & Deployments for Non-Technical Founders

Why a founder should care about this

Most founders I meet can describe every screen of their app. Very few can answer three simple questions: Where does it run? How does a fix reach users? What happens if the server dies tonight?

You do not need to become an engineer. But if you cannot answer those questions, you do not fully own your business. You depend on whoever can. This guide explains the moving parts in plain English and ends with a checklist you can hand to any developer, including us.

What a deployment actually is

Your app has two halves:

• The mobile apps (customer, driver, restaurant or provider) that people install from the App Store and Google Play.
• The backend: servers, a database and an admin panel that the apps talk to.

A deployment is the process of taking new code that a developer wrote and putting it where users actually get it. For the backend, that means copying the new version to the server and restarting services. For mobile apps, it means building a signed package, uploading it to Apple and Google, passing their review and releasing it.

Done badly, deployment is a developer logging into the server at night, copying files by hand and hoping nothing breaks. Done well, it is a repeatable, documented, mostly automatic process that anyone on the team can run, and undo.

Environments: development, staging and production

Professional teams never test new code on the live system. They keep separate copies, called environments.

Staging is the one founders most often skip to save money, and the one they most regret skipping. Without it, every update is tested on real customers. With it, you can place a test order, complete a test ride, and check that the new version works before anyone outside your team sees it.

CI/CD in plain English

CI stands for continuous integration. Every time a developer saves a change to the shared code repository, an automated system builds the app and runs its tests. If something breaks, the team knows within minutes, not when a customer complains.

CD stands for continuous delivery (or deployment). Once the tests pass, the same system packages the new version and deploys it, first to staging, then to production after someone approves it.

In practice, this lives in tools such as:

• GitHub Actions. Built into GitHub. According to GitHub's billing documentation, it is free for public repositories on standard runners, and private repositories get 2,000 included minutes per month on GitHub Free and 3,000 on GitHub Pro.
• GitLab CI/CD. Built into GitLab, with a similar model of included compute minutes and paid tiers.

For a small on-demand platform, those included minutes often cover a lot of routine work. The cost is mostly the time to set it up properly once.

Automated tests

Tests are small programs that check the main things your system must always do: a customer can sign up, an order can be placed, a fare is calculated correctly, a payment callback is recorded. They will not catch everything, but they catch the embarrassing mistakes before your users do.

One-click rollbacks

Every release will eventually contain a bug. The question is how fast you recover. A good pipeline keeps the previous version ready, so going back is one action, not an evening of panic. Ask your developer: "If tonight's release breaks ordering, how long until we are back on yesterday's version?" The right answer is minutes.

Hosting: where your backend lives

There are two broad choices.

A VPS (virtual private server)

A VPS is a rented virtual machine with a fixed monthly price. You (or your developer) install and manage the software on it. It is cheap and predictable, and for an early-stage marketplace it is often enough.

Examples from providers' own pricing pages, checked in October 2026:

Prices change, and locations differ (Hetzner's US and Singapore locations are priced differently), so always check the provider's page on the day you buy.

Managed cloud

Managed cloud services (managed databases, auto-scaling app platforms, managed Kubernetes and similar products from AWS, Google Cloud, Azure and others) take over much of the server work: patching, failover, scaling. You pay more per unit of computing, and bills can grow in less predictable ways, but you need less hands-on server administration.

Which one should you choose?

There is no single right answer. We choose per client, based on expected traffic, budget and who will look after the system. A common, sensible path is to start on a right-sized VPS with good backups and monitoring, then move specific pieces (usually the database first) to managed services when traffic or risk justifies it. Paying for enterprise-grade infrastructure before you have customers is a common way to burn runway.

The boring things that save your business

Backups: the 3-2-1 rule

Backblaze summarises the classic rule as keeping three copies of your data on two different media with one copy off-site. For an app, that usually means:

1. The live database.
2. Automated daily (or more frequent) backups stored separately from the server.
3. A copy in a different provider or region, so one account problem or one data-centre incident cannot wipe out everything.

And one more rule that matters more than the others: test restoring a backup. A backup you have never restored is a hope, not a backup.

Monitoring and uptime alerts

You should find out the app is down before your customers tell you. Uptime services check your site or API every few minutes and alert you by email, SMS or chat. UptimeRobot's pricing page, for example, lists a free plan with 50 monitors at a 5-minute interval, with paid plans from $9 per month billed annually (October 2026). Beyond uptime, good teams also watch server CPU, memory, disk space and error rates.

Logs

Logs are the system's diary: every error, failed payment callback and crashed request. When a customer says "my order disappeared", logs are how you find out what happened. Ask that logs are kept for a reasonable period and that someone actually reads the error logs.

SSL certificates

The padlock in the browser and the encrypted connection between apps and server come from an SSL/TLS certificate. Let's Encrypt provides them at no charge; its FAQ says default certificates are valid for 90 days and recommends renewing every 60 days. Renewal must be automatic. An expired certificate can make apps stop talking to the server.

Security updates

The server's operating system, database, runtime (such as Node.js or Go) and every library in your code receive security fixes. Someone must apply them regularly, and test them on staging first. Unpatched servers are one of the most common ways small businesses get breached.

The mobile release pipeline

Mobile apps add a second pipeline, because Apple and Google sit between you and your users.

• Fastlane is a widely used open-source tool for automating iOS and Android builds, code signing, screenshots and uploads to the stores.
• TestFlight is Apple's beta testing service. Apple's TestFlight page lists up to 100 internal testers from your team and up to 10,000 external testers; the first build for external testing must be approved by App Review.
• Google Play testing tracks. Internal, closed and open testing tracks let you send builds to your team and to wider groups of testers before a public release.

One important trap for new Android accounts: Google requires developers with personal accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for at least 14 days before the app can be published. If you are launching on a personal account, plan those two weeks into your timeline.

Signing keys: guard them

Every Android and iOS app is signed with keys that prove updates come from you. Lose control of them and you can lose control of your app listing. Make sure you know where your signing keys and passwords are stored, and that they belong to your company's accounts, not a freelancer's personal one.

How we set this up at Joldisoft

For custom builds, our stack is Flutter (with GetX) for the Android and iOS apps, React or Next.js for web frontends and admin panels, Node.js for most backends and Go for ride-hailing dispatch where high concurrency matters, PostgreSQL for data, WebSockets for real-time updates and Firebase Cloud Messaging for push. Hosting is a VPS or cloud server chosen per client. Whatever the stack, the principles in this article are the same: separate environments, automated builds, rollbacks, backups, monitoring and documented releases.

The checklist: what to demand from any developer

Print this. Use it with us, with a freelancer, with any agency.

• Repository access from day one. The code lives in a GitHub or GitLab account owned by your company, and you are an owner or admin.
• Store accounts in your company's name. Apple Developer and Google Play Console accounts belong to you; developers are invited as users.
• Server and domain accounts in your name. Hosting, domain registrar, DNS, maps, payment, SMS and Firebase accounts are yours.
• A staging environment that mirrors production, with test payments.
• Documented deployments. A written, step-by-step release process that someone else could follow.
• CI that builds and tests automatically on every change.
• A rollback plan measured in minutes.
• Automated backups, stored off the server, with a tested restore.
• Uptime monitoring and alerts going to you, not only to the developer.
• Automatic SSL renewal.
• A security update routine, tested on staging first.
• Signing keys and credentials stored safely, with you knowing where.
• A handover document: architecture, accounts, environment settings and contacts.

If a developer resists any of these, ask why. There are rarely good reasons for a client not to own their own code, accounts and backups.

The bottom line

You do not need to understand every command your developer runs. You do need to know that there is a staging copy, that releases are repeatable and reversible, that backups exist off the server and have been restored, that someone is watching uptime, and that every key account is in your name.

Get those right and a bad night becomes a ten-minute rollback. Get them wrong and one bad night can end the business.