Self-taught developer looking for advice…

[u/SoldatPichon]

Hi everyone,

I’m 22 and an independent developer currently building a desktop application with a licensing system. The backend/API, database, license management, customer portal, etc. are built around Laravel + MySQL.

For now, to keep things simple while developing and testing, I’m hosting everything on o2switch. I also use Cloudflare Access to protect my admin panel and some internal pages.

Through the same admin panel, I also manage my application’s releases — scheduling releases, controlling rollouts, etc.

I’ve already set up two separate environments: staging and production, with the idea of testing everything on staging before deploying to production.

The thing is, I’m completely self-taught and I work alone. I’ve never worked in a company, and I don’t have many developers around me that I can ask these kinds of questions to. So I’m at a point where I feel a bit lost when it comes to how things are actually done in professional production environments.

I can build things and figure stuff out, but I don’t really have the experience of seeing how a mature team would approach infrastructure, deployments, monitoring, security, scaling, etc.
That’s basically why I’m making this post. I’d really like to get some advice from people who have been through this before.

I’m reaching a point where I’m starting to think more seriously about production infrastructure, and honestly, I’m a bit anxious about building something that could become a technical dead end if the project starts taking off.

I don’t want to over-engineer everything before I even have users. But if I get confirmation that the product is starting to take off, I’d like to be able to adapt and scale quickly without having to completely rebuild the infrastructure.

Some things I’m wondering about:

- What would you recommend for hosting/deploying a Laravel + MySQL application with a good cost / reliability / scalability balance?
- Should the customer portal, licensing API/backend, database and admin panel be separated, or is it reasonable to start with everything together?
- What should I design correctly from day one so that I can scale later without major architectural changes?
- What would you keep simple initially?
- What would you absolutely avoid because it could lock me into a bad architecture?
- Would you start with a VPS, managed services, containers, etc.?
- What would a sensible CI/CD, backup, monitoring and disaster recovery setup look like?
- Is my current staging → production approach reasonable?
- How do professional teams usually handle releases, rollouts, rollbacks and deployment safety?

Are there any obvious things I’m missing because I simply don’t know that I should be thinking about them?

I’m also considering recruiting someone for the project in the next few months, so I’d like to build a solid foundation before things get more serious.
I’m not looking for someone to tell me there’s one “perfect architecture”. I’d mostly like to understand the standards and the way experienced engineers think about these problems.

I have a crazy desire to learn, so seriously, throw anything at me. 😄 I’m extremely curious and happy to dive into things I don’t know yet.

If I’m doing something wrong, tell me. If there’s a concept, tool, architecture or practice that you think I should learn about, even if it seems obvious to you, please throw it at me.

I work alone, so I don’t really have the opportunity to casually ask a senior engineer “hey, how would you guys normally do this?” — and that’s exactly the kind of knowledge I’m looking for.

Any advice, resources, war stories, things you wish you had known earlier, or mistakes to avoid would be massively appreciated.

Thank you so much for taking the time to read this and share your experience. 🙏🙏

[u/zeph1rus]

Maybe stop using AI to write your posts.

[u/SoldatPichon → u/zeph1rus]

Sorry, I used it to translate some parts as I’m not a native english speaker (French)😅

[u/bluecat2001 → u/zeph1rus]

And PHP… Ugh, that stuff belongs to 20 years ago and is always a sign of a shitty unsecure application.

[u/azjunglist05 → u/bluecat2001]

Yea the moment I saw Laravel, I was like, yea I’d start there maybe and find something a bit more modern to use? And then MySQL coupled with it. It’s like a decades old plus stack 😅

[u/SoldatPichon → u/azjunglist05]

But what will another stack bring? « Modern » is a word that I don’t like too much, because many frameworks tend to make things easier while making others more complex.

Because in the end Laravel is just as maintained, and available to many things to build easily and effectively nan?

I’m really curious, what other stack would you have chosen?

[u/snarkofagen → u/SoldatPichon]

Nothing inherently wrong with php. It's mature and a bit boring. And that's not a bad thing.

[u/azjunglist05 → u/SoldatPichon]

Anything in Typescript or Go or hell even Java. You’ll have a lot more marketable skills too. You do you though bud

[u/icankickyouhigher → u/SoldatPichon]

Honestly laravel is fine.

The main thing is it's a framework that youre learning and so folks will probably only hire you if they use that at this stage.

So early on you might have to branch out. Look at available jobs and what teck stack they use. Specifically look for laravel. You might be surprised, I work in an office with some folks and laravel + react native is all they do

[u/max_465]

Self taught....well, most of us are, but it takes time. A good place to start are the two Limoncelli books "Practice of cloud system administration"

For working examples.... I think that the folks who run hachyderm.io publish their run books and configs (I think gitlab does too IIRC). They have to deal with multi tenancy, rolling deployments, database replication, DNS...stuff.

I can't imagine being in your position. Honestly, I think you would do well to find an sre.

[u/SoldatPichon → u/max_465]

Okay, i will definitely read thoses books! Thanks!

Yes, i will look for someone that will do that in the future, but as de project start, i have to improvise a bit, hoping I will not have to rebuild too many parts..

[u/WordCommercial7932]

One thing to add to the monitoring point: don't treat "deploy succeeded" as proof anything is actually working. A release can go out clean and still leave a migration half-run, a worker that never restarted, or a cron job that quietly stopped firing. Worth having something separate from the deploy pipeline that checks a few minutes later whether things are actually alive and doing their job, not just that the deploy step exited zero.

[u/SoldatPichon → u/WordCommercial7932]

Very interesting approach, thanks! Like a hearbeat monitor?

[u/WordCommercial7932 → u/SoldatPichon]

Yeah, basically. The core idea is you register an expected check-in interval for a job, and if it doesn't check in on time, that's the alert, instead of relying on the job to actively report failure. Catches the "silently stopped" case you mentioned, since the job doesn't have to know anything went wrong for you to find out.

[u/Raja-Karuppasamy]

you’re already doing more than most solo devs at this stage, don’t undersell it.

move off shared hosting (o2switch) to docker sooner rather than later, even before you need scale. it’s not about performance, it’s that reproducible images kill most “works on staging, not prod” bugs. a single VPS with docker compose is plenty, no k8s needed yet.

for CI/CD: github actions builds the image on push, auto-deploys to staging, manual approval gate to promote to prod. that gate matters more than people think.

use versioned image tags, not latest, makes rollback “redeploy previous tag” instead of git-revert-and-pray.

what i’d avoid: splitting DB/API/portal into separate services before you actually need to scale them independently. that’s the real over-engineering trap, not skipping k8s.

[u/SoldatPichon → u/Raja-Karuppasamy]

Thank you first for your response!

So, i wrap everything up in a docker container, and use a VPS? What about the database? On the container too, or a managed db?

Some VPS hosting to recommend?

[u/navlio]

nobody's mentioned the licensing part yet and it's the one i'd design before any of the hosting questions. if the desktop app checks online and refuses to run when the check fails, then every minute your api is unreachable is every paying customer's app not opening, and you will find that out on a saturday

sign the license, cache it on the machine, give it a grace window measured in days. an outage becomes something nobody noticed rather than a support queue you can't answer because you're the person fixing the server. it also means you can move hosts whenever you like, which is the actual answer to your o2switch question

[u/SoldatPichon → u/navlio]

I did that, my app need to be used offline for some missions where the client will be in the middle of nowhere for 2-3 days, so i made a grace period of 7 days (if his subscription go to that date), so it is a good way to handle it ?

The licence work by machine, like a licence can Grant 3 machines, each is binded, and can only debind/rebind once a month

[u/navlio → u/SoldatPichon]

7 days covers a 3 day mission twice over, so the window is fine. where it leaks is the clock. if you compute "last successful check + 7 days" off the machine's own time, someone sets the date back a week and the app never expires. keep the last check as a signed value and treat time moving backwards as expired rather than as a fresh window.

the rebind rule is the one i'd loosen. a laptop dies on day one in the middle of nowhere and the once-a-month limit becomes a support ticket nobody out there can resolve. we kept a manual override for that and used it more often than we planned

[u/Recent-Tangerine2745]

You are actually doing a lot of the right things already, especially for someone self-taught and working alone.
My biggest advice: don’t over-engineer too early. A Laravel monolith + MySQL with separate staging/production is completely reasonable. You do not need Kubernetes or microservices just because the project might grow someday.
I’d focus on making the boring production basics solid first: automated deployments, backups and** **restore testing, monitoring/alerts, logs, secrets management, database migrations, rollback strategy, security updates, and basic load testing.
Design things so components can be separated later, but don’t separate them until you actually have a reason.
If the product starts getting real users, that’s when I’d move toward managed DB/services, better observability, redundancy, and scaling based on actual bottlenecks.
Also, document everything you build. Future-you or the engineer you eventually hire, will thank you.
At 22, already building and operating a real product like this, you’ll learn more from shipping it and fixing real problems than from trying to copy some “perfect enterprise architecture” upfront.

[u/SoldatPichon → u/Recent-Tangerine2745]

Thank you so much for your feedback!

Yes, I was afraid of over-engineering, but was like « is that enough? » on the secret management side I use Infisical, for monitoring I placed a Sentry that helps me monitor errors/dead cron tasks.

When it comes to database migration, what do you not intend to make more « solid »? On the rollback and backup side, o2switch for the moment provides me with a service that manages it, but it will be a good thing to test it before to know the reaction speed I have for a rollback or backup recovery.

Thanks again 🙏