Building a Product While Working Full-Time: How I Structured Time, Teams, and Learning Around JED

Someone once asked me on X (Twitter):

“How did you combine a full-time commitment with building a product?”

It is a fair question.

From the outside, product building often appears to be a straightforward story of discipline and long coding hours.

In reality, balancing a full-time role while actively evolving a production product involves tradeoffs, planning, technical decisions, learning curves, and deliberate time allocation.

This article walks through how I approached that process while working on JED.

Before AmaliTech: Building JED Started Earlier

My team and I originally built JED in 2024 while still in school.

Before joining AmaliTech for my National Service, the product already existed; we had engineering workflows, responsibilities, and a shared direction.

In 2025, we decided to rewrite the platform into what became JED v2.0.

That version ran, delivered wins, onboarded users, processed transactions, and, more importantly, produced feedback.

Lots of feedback.

Like most products, success did not reduce complexity. It introduced new architectural questions.

That eventually led us toward another major engineering decision.

Rewriting the Stack in 2026: Why We Moved Parts of the System to Go

Initially, significant parts of our backend systems and USSD infrastructure were built with JavaScript/TypeScript.

After several technical considerations, we made the decision to rewrite major backend systems and USSD flows in Go.

This was not a “rewrite for fun” decision.

It came from evaluating where we wanted the platform architecture to evolve and what tradeoffs made sense for us operationally.

The rewrite created a secondary challenge:

I needed to intentionally upskill in Go.

Fortunately, I already had previous backend engineering experience, so transitioning was relatively smooth. But learning still required dedicated effort.

Instead of treating learning as a separate activity, I treated it as part of the engineering roadmap.

I boxed time for it.

That became an important pattern throughout this journey.

Time Boxing Product Development Around Full-Time Work

While working at AmaliTech, I maintained a simple rule:

Weekdays belonged to my primary responsibilities. Weekends belonged to JED.

I made sure I did not leave outstanding deliverables hanging for my macro team.

Once work obligations were cleared, my product schedule typically looked like this:

• Friday night coding sessions
• Saturday build time
• Sunday afternoon planning, shipping, or debugging

Was it always comfortable?

No.

There were many days when returning from work already meant operating on limited energy.

But structure mattered more than motivation.

Team Structure Reduced Bottlenecks

One thing that made this sustainable was that I was not attempting to own every moving piece single-handedly.

Roles were distributed across the team.

Everyone had clear responsibilities.

That mattered because product development is rarely blocked by coding alone; it is often blocked by unclear ownership.

On my side, my responsibilities included:

• Frontend heavy lifting
• Backend service integrations
• Architecture decisions
• Building and versioning USSD application flows

Having defined ownership reduced dependency chains and allowed parallel execution.

Learning While Shipping

One important lesson from this period was that upskilling does not always need isolated study months.

Sometimes learning happens most effectively inside real engineering constraints.

The move toward Go reinforced this for me.

I was learning while designing, building, debugging, and shipping.

The product became the laboratory.

That does not eliminate the learning curve, but it grounds learning in actual problems rather than theoretical exercises.

Unscrumbling Trust

Both the team at work and at JED consistently trusted me to deliver when it mattered most. Over time, this came from being reliable in execution, staying aligned with expectations, and collaborating effectively across both environments without creating bottlenecks.

Key Takeaways

Looking back, a few things mattered significantly:

• Protect your primary responsibilities.
• Time box personal projects intentionally.
• Define ownership early within your team.
• Learn technologies through meaningful application.
• Do not rely exclusively on motivation; rely on systems.

Building a product while working full-time is possible.

But sustainability usually comes from structure more than intensity.