Full-Stack Engineer — Business Systems (AI-Native)
Whitespace Solutions · Jakarta, Indonesia (Hybrid) · Full-time
WHO WE ARE
Whitespace Solutions is a Jakarta-based consultancy that builds AI-augmented business software. We build it for clients, and we build our own products. We're a small, growing engineering team. You'd work directly with the founder who sets the architecture, alongside a business analyst who models the client's process.
Your time splits roughly 50/50 between client delivery and our own products. That means moving between codebases and domains, sometimes within the same week: retail and inventory, ERP-style operations, document automation.
THE ROLE
We're hiring early-career engineers (roughly 1–3 years of experience, or fresh graduates who can show the ability). You'll turn business workflows into reliable software and ship features end to end: UI, API, and database.
We work agent-native: coding agents investigate, implement, test and review alongside us. That makes plausible code cheap. What stays scarce is judgment: knowing what good software looks like, why it's good, and when the agent is confidently wrong. That's what we hire for. We expect you to learn fast and largely on your own, using agents, docs and code review rather than formal training.
The question we care about: can you use AI as leverage without outsourcing your judgment to it?
WHAT YOU'LL DO
- - Build features end to end: screens in React/Next.js, APIs in TypeScript or Python, schemas and migrations in PostgreSQL.
- - Turn an analyst's process map into data models, state transitions and permissions.
- - Integrate with clients' existing systems (ERPs, POS, spreadsheets, third-party APIs) rather than replacing them.
- - Build AI-assisted workflows, such as extracting structured data from documents, with source tracing and human review.
- - Direct coding agents through investigation, implementation and testing, then review their diffs before anything ships.
- - Write tests for the dangerous paths: concurrent updates, retries, partial failures.
- - Debug issues from symptom to root cause instead of patching the surface.
- - Join client sessions to clarify requirements, run UAT, and explain how the system behaves.
- - Improve our engineering system: tests, CI gates, docs, agent instructions.
WHAT YOU'LL WORK ON
Recent and current work includes:
- - a POS and inventory platform for a multi-store retail chain;
- - a tender pricing and quote-to-cash engine for an enterprise services company;
- - AI document extraction that reconciles accounts-receivable records against source documents;
- - an AI sales role-play and coaching platform, our own SaaS product;
- - an ERP rollout, including integrations with the client's existing systems.
The analyst models the process. You turn it into working software, and you ask the technical questions the requirements missed:
- - What is the source of truth for product master data, and which systems may only read it?
- - Two cashiers sell the last unit at the same moment. What happens?
- - Should this validation live in the UI, the service layer, or a database constraint?
- - A downstream system is down. Fail, retry, queue, or degrade? And what does the user see?
- - How do we prove a generated document field came from the right source?
A representative task, once you're ramped up: A branch receives stock from a distributor. Compare the delivery against the order, record discrepancies, update trustworthy stock, keep an audit trail, and behave sensibly if part of the process fails. You'd:
- - identify the entities and state transitions, plus the failure and concurrency cases;
- - design the schema and API, and the screens a branch user works in;
- - implement it with agents;
- - test the dangerous paths;
- - explain the design.
HOW WE WORK
The repository is part of how engineering runs, not just where the code lives. It holds the specs, the architecture decisions and invariants, workplans with acceptance criteria, agent instructions, tests and CI gates. These make intent legible to humans and agents alike, so important rules are enforced mechanically rather than remembered. Improving that system (tests, gates, docs, agent instructions) is part of the job.
"Done" means evidence: what was tested or observed. "The agent says it works" is not verification. Agents do engineering work. Authority over risky actions stays with people.
The founder reviews your designs and the evidence for your changes. That makes you the first line of review on the code itself, including code an agent wrote. Expect your design choices to be questioned; that's how you'll learn.
NEEDED AT ENTRY
- - Solid programming fundamentals in TypeScript and/or Python.
- - Can build a feature end to end: a React/Next.js interface, the API behind it, and the data underneath.
- - Working SQL and relational modeling: keys, constraints, joins, indexes.
- - Reading unfamiliar code, including an agent's diff, and accurately explaining what it actually does.
- - Explaining why you chose an approach, not just that it works.
- - A habit of verifying your own assumptions.
- - Comfort with AI coding tools, or eagerness to work this way.
- - You learn new tools and domains fast, on your own.
- - Working English (code and docs are in English) and fluent Bahasa Indonesia for analyst and client conversations.
WHAT YOU'LL GROW INTO
- - Failure-scenario thinking: what breaks, when, and how badly. Think load, concurrency, dependency outages and partial failure.
- - Transactions, concurrency, idempotency and safe retries.
- - Putting business rules where they can actually be enforced: the database is part of correctness, and UI validation alone is not enough.
- - Interfaces that tell the truth about system state: pending, failed, partially applied.
- - Integration design, queues and background jobs, auditability.
- - Code taste. That means clear ownership, cohesive modules, explicit contracts, and abstractions that exist for a reason. It also means spotting the warning signs: duplicated rules, multiple writers to one source of truth, catch-all error handling, unsafe migrations.
- - Directing agents well. Give context, outcome and constraints; have the agent investigate before it implements; read diffs, not summaries.
USEFUL, NOT REQUIRED
- - ERP, POS, inventory or procurement domains
- - LLM APIs and RAG
- - ETL/ELT basics
PROBABLY NOT A FIT IF YOU
- - need detailed tickets before you can make progress;
- - optimize for making the test pass rather than making the system correct;
- - treat the database as passive storage;
- - add abstractions or technologies without a concrete reason;
- - aren't curious about the business behind the code.
HOW WE THINK ABOUT EXPERIENCE
The range is flexible. A one-year engineer who reasons clearly can outperform a three-year engineer who has only followed tickets. The answer we like hearing is: "I don't know yet. Here's what I'd inspect, the trade-offs I think matter, and the evidence I'd want before choosing."