Forced In-Person Work: When Contractors Are Treated Unfairly

by Arif Ikhsanudin, Backend Developer

“We require all contractors to be onsite five days a week.”
That sentence often signals a deeper misunderstanding of what contracting actually is.

When Contracting Starts Looking Like Employment (Without the Benefits)

Contractors are usually brought in for flexibility and focused expertise.

But forced in-person policies change the equation quickly:

  • Fixed office attendance becomes mandatory
  • Work is tied to physical presence, not output
  • Daily routines mirror full-time staff expectations

At that point, something feels off.

The role is still “contractor” on paper—but functionally it starts looking like employment.

The Unequal Exchange Behind Mandatory Office Days

The core issue is imbalance.

Contractors are expected to:

  • Follow strict office schedules
  • Adapt to internal systems and processes
  • Be physically present like employees

But they don’t receive:

  • Job security or long-term guarantees
  • Employee benefits or protections
  • Organizational influence or stability

And that gap matters.

  • Responsibility increases without compensation structure changing
  • Flexibility decreases without added support
  • Control becomes one-sided

It’s not just about location—it’s about fairness in expectations.

Why Forced Presence Hurts Contractor Productivity

In-person requirements sound productive on the surface.

But for contractors, they often reduce efficiency:

  • Commute time eats into focused work hours
  • Office distractions interrupt deep technical thinking
  • Fixed schedules break personal optimization rhythms

Many contractors are hired precisely because they work best independently.

  • They design their own environment for output
  • They optimize for task completion, not attendance
  • They often juggle multiple engagements

Forcing presence removes the very advantage they were hired for.

The Subtle Shift Into “Disguised Employment”

Over time, forced office policies can blur boundaries completely.

Contractors start experiencing:

  • Internal tracking like employees
  • Social expectations of team integration
  • Informal pressure to behave like staff

But without the protections staff receive.

  • No paid leave
  • No benefits
  • No long-term stability

That’s where contracting stops being independent work and starts becoming disguised employment.

A Better Way to Structure Contractor Work

Healthy contractor relationships are built on clarity, not control.

Better approaches include:

  • Define deliverables, not attendance rules
  • Allow flexible work environments
  • Reserve office presence for collaboration, not enforcement

A simple principle helps:

  • If you control how and where the work is done daily, it’s employment
  • If you control what outcomes are delivered, it’s contracting

Respecting that boundary improves trust on both sides.


Forced in-person work may feel like alignment.
But for contractors, it often becomes a quiet form of unfair constraint that reduces both efficiency and independence.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

How I Balance Writing Code and Leading a Team at the Same Time

Staying technical as a tech lead is not about protecting your identity as a developer — it's about being a credible, useful leader. But doing it well requires real boundaries and deliberate choices.

Read more

Why Your Containers Can't Talk to Each Other

Container-to-container communication failures almost always trace back to a small set of root causes: wrong hostname, containers on different networks, or a service not actually listening on the expected address. Here's how to diagnose each one.

Read more

Error Handling in Ruby — Beyond Rescue and Raise

Most Ruby codebases use rescue and raise for everything, which conflates recoverable domain failures with unexpected system errors. Here is a structured approach to error handling that scales past a few controllers.

Read more

Java Streams Are Lazy — What That Means for Performance and Correctness

Stream intermediate operations do not execute until a terminal operation is called. This laziness enables short-circuiting, infinite streams, and fusion optimizations — and causes correctness bugs when side effects are assumed to have already fired.

Read more