Career
Balancing DevOps, ERP, and Web Dev as a Final-Year Engineering Student
April 20267 min readUpdated Jul 14, 2026
Photo by Unsplash
It wasn't entirely a deliberate choice — finishing a degree at Swiss German University while working part-time as a DevOps engineer at Commsult Indonesia and building web apps and ERP systems on the side created the multi-domain situation organically. The original entry point was DevOps through Linux and Docker coursework, which led to the part-time role at Commsult, which then introduced ERP work. The breadth emerged from following genuine interest and opportunity rather than a pre-planned strategy.
The hardest part isn't technical depth — it's the mental mode shift required between domains. DevOps demands a systems mindset focused on failure modes and monitoring, ERP requires a business logic mindset around approval hierarchies and data integrity, and web development calls for a product mindset centered on UX and performance. Switching between these modes mid-day is described as genuinely cognitively expensive, with the overhead concentrated in the ramp-up rather than the actual work.
A key habit is writing three bullet points at the end of every work session summarizing where you left off and what the next step is — a ritual that costs 2 minutes but saves 20 minutes of warm-up time the next session. More broadly, time management relies on time-blocking by domain (not by task), context notes at session end, and ruthless scope limitation on side projects. The biggest lever is saying no to interesting things that don't fit the current focus.
DevOps knowledge makes web development stronger — understanding how Nginx serves Next.js, how to configure cache headers, and how to set up staging environments. ERP work builds better systems thinking because business logic has invariants and edge cases more complex than most tutorial examples. Web development in turn makes for a better DevOps engineer when building user-facing internal tools, since UX requirements are already well understood.
The real risk isn't burnout — it's staying permanently shallow across all domains and never building genuinely novel solutions in any of them. The recommended countermeasure is setting a quarterly depth goal in one domain to push past surface-level familiarity. The underlying principle is that multi-domain breadth opens doors, but depth in at least one area is what makes an engineer hireable for serious roles.
Photo by Unsplash
Key Takeaway
Balancing DevOps, ERP development, and web app development at once as a student is workable if approached deliberately: block time by domain instead of by task, write short context notes at the end of every session, and set a quarterly depth goal in one domain so shared breadth across all three never leaves you permanently shallow everywhere.
Most career advice says to specialize early, go deep in one area, and let breadth come later. I went the other way — not entirely by choice. During my final year at Swiss German University, while working part-time as a DevOps engineer at Commsult Indonesia and building custom web apps and ERP systems on the side, I was constantly context-switching between three distinct technical domains. It was harder than I expected and more rewarding than I anticipated. This is an honest account of how it actually worked.
It started with DevOps. I got into Linux and Docker through university coursework, built a few side projects on DigitalOcean, and found that I genuinely enjoyed infrastructure — the precision of it, the way a well-configured CI/CD pipeline becomes invisible and reliable. That led to the part-time role at Commsult, which is a consulting firm that builds and maintains ERP systems for Indonesian businesses. Suddenly I was also doing ERP: NestJS backends, approval workflows, accounting modules, HR leave management.
The hardest part isn't the technical depth — it's the mental mode shift. DevOps work requires a systems mindset: thinking about failure modes, network topology, resource limits, monitoring signal vs noise. ERP development requires a business logic mindset: understanding approval hierarchies, accounting rules, data integrity constraints. Web development requires a product mindset: user experience, performance perception, visual hierarchy. Switching between these modes mid-day is genuinely cognitively expensive.
Swiss German University ran a curriculum that was broader than most Indonesian universities, with coursework in operating systems, cloud computing, software engineering, and a final capstone project. The academic work was both a burden and a gift at the time. It was a burden because it competed for time with paid work and side projects. It was a gift because it forced me to formalize knowledge I'd acquired informally.
BREADTH (general software engineering)
◄──────────────────────────────────────────────────────►
Linux │ Git │ SQL │ REST APIs │ TypeScript │ Bash │ Docker
──────┼─────┼─────┼───────────┼────────────┼──────┼───────
│ DEPTH │
▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ DevOps / │ │ ERP / │ │ Web App Dev / │
│ Cloud Infra │ │ Business │ │ Next.js │
│ │ │ Systems │ │ │
│ GCP, Docker │ │ Workflows, │ │ React, next-intl │
│ Nginx, CI/CD │ │ Approvals, │ │ TypeScript, │
│ Monitoring │ │ NestJS APIs │ │ Tailwind, SEO │
└──────┬───────┘ └──────┬───────┘ └────────┬─────────┘
│ │ │
└──────────────────┴─────────────────────┘
Each domain REINFORCES the others:
DevOps → deploy web apps & ERP in production
ERP → teaches real business logic for web apps
Web Dev → builds UIs for ERP & monitoring toolsWrite three bullet points at the end of every work session summarizing where you left off and what the next step is. This ritual costs 2 minutes and saves 20 minutes of warm-up time the next session. The cognitive overhead of multi-domain work is mostly in the ramp-up, not the actual work.
The unexpected benefit of multi-domain work is the cross-pollination. DevOps knowledge makes me a better web developer: I know how Nginx serves Next.js, how to configure proper cache headers, how to set up a staging environment. ERP work makes me a better systems thinker: business logic has invariants and edge cases that are more complex than most tutorial examples. Web development makes me a better DevOps engineer: building user-facing tools for internal teams is much easier when I understand the UX requirements.
The T-shaped engineer framework describes where I'm heading rather than where I am now. Right now I'm more like an M-shape: moderate depth in three connected areas, with shared breadth underneath. Shared breadth across all three domains includes: TypeScript, PostgreSQL, REST API design, Linux, Git, Docker, and basic networking. These fundamentals appear in every domain and investment in them is never wasted.
# My rough weekly rhythm during my final year of university (not always this clean, but aspirational)
MON–TUE │ DevOps / Infra work at Commsult
│ → VPS provisioning, CI/CD pipeline fixes,
│ monitoring alerts, cloud cost review
WED–THU │ ERP feature development
│ → NestJS backend: approval workflows,
│ invoice generation, RBAC, email triggers
FRI │ Web app / portfolio / side projects
│ → Next.js, Tailwind, SEO, performance tuning
WEEKEND │ Study: Swiss German University coursework
│ → Operating systems, cloud computing,
│ software engineering capstone
# Context-switching tricks I actually use:
# 1. End each block by writing 3 bullet notes: "where I left off"
# 2. Keep separate terminal workspaces per domain (tmux sessions)
# 3. Short 5-min "warm-up" re-read before diving in
# 4. Never mix domains mid-flow — finish the task firstIf I could give advice to myself at the start of this journey: embrace the breadth, but be intentional about it. Don't spread yourself thin by accident — spread yourself thin by design, with a plan for when and how you'll go deep. Document everything you learn, not for others, but for your future self. The knowledge accumulation compounds over time in ways that aren't obvious month-to-month but become unmistakable year-to-year.
The real risk of multi-domain work isn't burnout — it's staying permanently shallow. It's easy to touch DevOps every week, ERP every week, and web dev every week, but never go deep enough in any of them to build genuinely novel solutions. Set a quarterly depth goal in one domain to counteract this drift.
Time management across three domains and university comes down to a few non-negotiable habits: time-blocking by domain (not by task), context notes at every session end, and ruthless scope limitation on side projects. The biggest lever is saying no to interesting things that don't fit the current focus. The second biggest lever is automating the DevOps toil so it doesn't consume disproportionate time.
I don't plan to stay multi-domain forever. The strategy is to use the breadth as a foundation and converge on a primary specialty as opportunities crystallize. The three domains naturally converge toward building production software systems that run reliably — which describes most interesting engineering roles. Whether the primary specialty ends up being platform engineering, full-stack product engineering, or technical consulting, the three-domain foundation will have been worth it.
Update: I've since graduated from Swiss German University and now work full-time as a DevOps Engineer at Commsult Indonesia. This post is a snapshot of my final year, when I was still balancing the degree with a part-time role — the three-domain habits described above are still exactly how I work today.