API Design and System Architecture

The Most Expensive Technical Mistake Is Building Without a Plan

You can recover from bad code. You can refactor ugly implementations. You can fix bugs. What you cannot recover from cheaply is a fundamentally wrong architecture — a system designed around the wrong assumptions, with integration seams in the wrong places, or a data model that doesn't support the queries your business actually needs.

When architecture goes wrong, you don't fix it — you rebuild it. And rebuilding costs more than building right the first time by a factor of three to five.

API design and system architecture is the discipline of getting the foundational decisions right before they become expensive. At NICKTUNG, we offer this as a standalone service — working with your team to design the system you'll build, so the builders can execute with confidence rather than discovering structural problems mid-project.

What System Architecture Design Produces

A system architecture engagement with NICKTUNG delivers concrete artefacts that your development team — internal or external — can build from:

• System context diagram — what your system does, what it connects to, and where its boundaries are
• Component architecture — how the system is divided into services, what each owns, and how they communicate
• Data model — the entity relationships, key tables, and data flows that support your product's requirements
• API contract design — OpenAPI specifications for every interface, documented before a line of implementation is written
• Technology selection — recommended stack with the rationale documented in Architecture Decision Records (ADRs) so future engineers understand why choices were made
• Non-functional requirements coverage — how the architecture addresses performance, security, scalability, observability, and disaster recovery
• Build sequence — a phased delivery plan that delivers working software incrementally, with the highest-risk architectural elements validated early

API Design as a Product Decision

API design is not purely technical. Every design decision in an API has consequences for the businesses and developers who consume it. A well-designed API is easy to understand, predictable in behaviour, and forgiving of mistakes. A poorly-designed one generates support tickets, integration bugs, and eventual rewrites.

The patterns that make APIs work in the long term:

• Resource-oriented design — modelling around the things that exist in your domain, not the operations your system performs
• Consistent naming and structure — following conventions so developers don't need to re-learn every endpoint
• Meaningful error responses — machine-readable error codes with human-readable messages that tell developers exactly what went wrong
• Versioning from the start — not as an afterthought, but as a first-class concern that protects existing consumers as the API evolves
• Backward compatibility discipline — never removing fields or changing semantics without a versioned migration path

Monolith First: The Architecture Nick Actually Recommends

There's a pattern common in Singapore tech circles — designing microservices architectures for products that don't have the scale or team structure to justify the operational complexity. Distributed systems are genuinely hard. The coordination overhead, the deployment complexity, the network reliability requirements — all of these are real costs that small and medium-sized teams pay every day.

NICKTUNG recommends monolith-first architecture for most SME projects: a single, well-structured codebase with clear internal module boundaries that can be extracted into separate services later — if and when the specific problem that microservices solve actually arrives. Most SME products never need to make that extraction.

This isn't a backward approach. It's what the most experienced engineers at the best engineering organisations advocate. Martin Fowler calls it "Monolith First." We call it building for the business you have.

Architecture for Singapore's Security and Compliance Context

Architecture decisions that look purely technical often have regulatory consequences. In Singapore:

• Where you store personal data matters for PDPA accountability
• How you architect audit logging matters for MAS Technology Risk Management guidelines
• How you design privilege boundaries matters for CSA Cyber Essentials compliance

NICKTUNG designs with the Singapore regulatory context in mind as a default, not an add-on. This saves expensive retrofitting when audits reveal gaps.

What an Architecture Review Engagement Looks Like

Architecture engagements typically run 2–4 weeks, producing the full design documentation described above. Fees range from S$30,000 to S$80,000 depending on system complexity, with EDG grant support available.

We also offer targeted Architecture Review sessions — a focused 1–2 day engagement that audits an existing architecture against specific concerns (security, scalability, maintainability) and produces a ranked remediation plan.

Frequently Asked Questions

We have existing developers. Can you work with them rather than replacing them?

Yes, and this is often the best model. Architecture design work requires a different skill set and perspective than implementation. We provide the architectural direction and the documented plan; your team (or the team you hire) executes it. We can also review pull requests and participate in technical discussions during the build phase to ensure the implementation stays aligned with the architecture.

How do we know the architecture you design will actually work?

We prototype the highest-risk elements — the architectural decisions where "this might not work" is a genuine concern — before committing to a full implementation plan. For API designs, we build stub implementations that consumers can test against. For data model decisions, we validate with sample queries. We don't ask you to bet on untested designs.

What's the difference between a technical architect and a solutions architect?

Technical architects focus on the internal structure of the system — components, data flow, code organisation, performance patterns. Solutions architects focus on how the system fits into the broader business and technology landscape — vendor selection, integration points, total cost of ownership. NICKTUNG's PMC (Practicing Management Consultant) certification means we bridge both: designing technically sound systems that serve business goals, not just technical elegance.

Build the right thing before you start building. Talk to NICKTUNG about an architecture engagement — it's the investment that makes every subsequent investment pay off better.