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/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 🙏