Alone as the Only Developer in a Startup: My First-Year Reality Check Part 2

The part where things started breaking for real

After building and deploying my first application, I thought the hardest part was over.

I was wrong.

The first deployment was hosted on my personal VPS account. The company told me they would reimburse the cost later, which sounded reasonable at the time. But weeks passed, and nobody brought it up again.

Eventually, I had to ask for the reimbursement myself.

By then, the VPS subscription had already expired.

I decided not to renew it from my own pocket again. I had already spent enough money and energy trying to keep things running. So I asked the company to provide a VPS directly instead of routing everything through my personal account.

They agreed.

Or at least, they said they would.

At the same time, they handed me another project.

A Risk Management System.

Which was basically an audit management platform.

And once again, the process started the same way: vague explanations, unclear expectations, and a tight deadline attached to all of it.

I tried searching online for similar systems to understand what exactly they wanted, but nothing matched properly. Every example felt incomplete or too different from the company’s vision.

That’s when I realised something important.

Sometimes the internet is not the best teacher.

So instead of endlessly searching for templates and tutorials, I reached out to someone who actually worked in audit and compliance. I explained the application requirements as I understood them, and within minutes he pointed out flaws in my understanding.

A lot of flaws.

What I thought the system needed and what an actual audit workflow looked like were completely different things.

We spent almost an entire week discussing use cases, workflows, approvals, and reporting structures. By the end of that week, I finally had something I didn’t have before:

clarity.

For the first time, I had a plan that actually made sense.

Then development started.

And honestly, this is the part where I have to admit something uncomfortable.

The project took me almost two months.

Not because it technically required two months, but because I was immature and distracted.

The company wasn’t very attentive toward me during that period. Nobody was checking progress regularly. Nobody was asking questions. And instead of using that freedom responsibly, I started spending more time on my personal projects while pretending the company project was still “in progress.”

The application was already mostly complete.

I was just delaying things.

Looking back now, I understand how unprofessional that was. At the time, I justified it to myself because the environment already felt disorganised.

But avoiding responsibility doesn’t suddenly become okay just because the company is chaotic.

Eventually, near the end of the second month, they finally asked to see the application.

We had one meeting.

Then another.

Then a third.

And after all of that, they said one sentence that genuinely made my blood boil: “This is not what we wanted.”

I remember sitting there feeling frustrated, confused, and honestly exhausted.

Because from my perspective, I had built exactly what was discussed.

But at the same time, a small part of me also knew the real problem:

nothing had ever been properly defined in the first place.

So instead of arguing, I asked them to explain what they actually wanted.

That’s when the requirements completely changed.

Now they wanted something closer to a workspace platform. Different groups with isolated environments. Separate “bubbles” where teams could work independently without interfering with each other.

It was a completely different product direction from the original explanation.

But what option did I really have?

I agreed to make the changes.

Then, literally the next day, they told me to pause the changes and first deploy the already-built version to production.

So naturally, I asked for the VPS access they had promised earlier.

And once again, the answer was:

“Buy it for now, we’ll reimburse you later.”

This time, I refused.

Not aggressively. Just firmly.

I didn’t want company infrastructure tied to my personal account anymore.

That conversation dragged on for almost two weeks.

Then finally, someone else from the team stepped in. Ironically, this was someone who had never really helped me technically before. Mostly just someone who liked acting authoritative during meetings.

He finally said, “Fine, we’ll buy it.”

He told me to create a fresh email account, select the VPS package, and he would make the payment.

I did exactly that.

The VPS was finally purchased properly.

And after another two weeks of setup, migration, debugging, deployment, and stress…

both applications finally went live.

At that point, it was already the end of November.

Then came another phase entirely.

The co-founder suddenly wanted UI improvements for the Task Management System. So for almost a month, I kept making continuous frontend changes, refinements, layout fixes, workflow adjustments, and usability improvements.

And honestly, that period helped me a lot.

The project slowly stopped feeling like a “college assignment” and started feeling like an actual production application people could use daily.

Real users were now interacting with something I had built.

That feeling was satisfying.

For a while, things finally felt stable.

Then the malware attack happened.

The VPS suddenly went down.

At first, I ignored the call because it was already after working hours and I was busy with a personal project. Looking back, I should’ve checked immediately.

Eventually, the teammate who paid for the VPS called me and said the server wasn’t responding.

I logged in and saw the VPS had shut down completely.

I restarted it.

It worked again.

Then the next day, it crashed again.

This time I investigated properly.

The CPU usage was hitting 100% repeatedly until the VPS became unusable.

That was the moment I learned about cryptojacking.

Somehow, malicious processes had entered the server and were consuming resources in the background.

I explained the issue to the co-founder.

His response was simple:

“Just fix it.”

No panic. No technical discussion. Just fix it.

So that’s what I did.

I reset the entire VPS.

Deleted applications. Removed deployments. Cleaned everything. Reconfigured the server from scratch.

For three straight days, I rebuilt the entire environment while learning in real time about:

• firewall security
• VPS hardening
• SSL certificates
• malware prevention
• server monitoring
• deployment safety

It was stressful.

But weirdly, it was also one of the most valuable learning experiences I’ve had so far.

Because this time, I wasn’t just copying tutorials anymore.

I actually understood why things mattered.

That’s where Part 2 ends.

Part 3 will probably be the final part of this series, where I’ll talk about burnout, job searching again, and how this experience completely changed the way I think about work, startups, and growth as a developer.