Technical Architect — Product Engineering

Experience: 12+ years in software engineering, with at least 6 in product engineering

Notice period : immediate to 60 days preferred; buyout considered for the right candidate

Reports to: Delivery Manager, with a direct working line to the client's principal engineer

Engagement: Full-time/permanent on SUIPL payroll

About the role-

SUIPL is building a new multi-tenant SaaS platform for an international client. The client, the sector, and the product are confidential until launch. We are direct about that up front rather than hinting at it: the domain and commercial context are described in full under NDA at the final interview stage, and not before. What we can describe completely is the engineering, which is the part that should decide whether you want the job.

You are the senior technical owner of the build. Greenfield, no existing codebase, no inherited constraints. You set the data model, the domain architecture, and the service boundaries, and you carry those decisions through implementation. The pod grows from five engineers to ten around you.

The work is architecturally demanding rather than novel. It is a transactional system where correctness matters more than throughput: long-lived records edited concurrently by several people in different roles, strict auditability, financial accuracy, and a set of third-party dependencies that are unreliable in ways you have to design around rather than complain about. If you have built systems where a wrong write costs someone real money, you will recognize the shape of it.

Your architecture is reviewed and formally approved in writing by the client's principal engineer before implementation begins. If that reads as interference, this is not your role. If it reads as having a peer who will engage seriously with your design instead of rubber-stamping it, it is.

What you will own-

Domain and data architecture

- The multi-tenant data model: isolation strategy, row-level security, and what is shared versus partitioned. Isolation enforced structurally rather than by convention.
- The domain model for long-lived records that move through a defined lifecycle, including state transitions and independent validation of the parts within a record.
- The concurrency model. One system-wide answer to conflicting edits, including what the user sees when a conflict occurs, rather than a per-endpoint patch.
- Financial correctness: value representation, rounding, and reconciliation.
- The audit and change-attribution model, and the immutability rules that apply once a record is committed.

Services and interfaces

- Service boundaries and the API surface, including versioning and backward compatibility with clients you do not control.
- Asynchronous and event-driven processing: queues, scheduled work, retries, and idempotency guarantees.
- Adapter and anti-corruption layers for third-party dependencies, in place from the first commit,



so no external data model leaks into the core domain.
- Failure isolation and degradation strategy when an external provider is slow, wrong, or unavailable.
- Bulk data import architecture for onboarding customers who arrive with large volumes of poor-quality historical data.

Security and operability

- The authorization model — roles, permissions, and enforcement points — designed once rather than accumulated endpoint by endpoint.
- Encryption at rest and in transit, secrets management, and personal data handling.
- Compliance-grade technical controls designed into the architecture rather than documented around it afterwards.
- Observability by design: structured logging and tracing sufficient to reconstruct what happened to a specific record on a specific day.
- Performance and latency budgets, designed to a stated target rather than discovered under load.

Engineering standards and the team

- Written design documents produced before implementation, to a standard an external reviewer can assess without a meeting.
- The testing strategy: what is unit tested, what is integration tested, and what must never reach production untested.
- Code review standards, definition of done, and the technical debt register — including which debt is deliberate and when it gets paid.
- Technical mentoring for the pod, and technical assessment of engineers hired after you.
- Decomposing architecture into work the Delivery Manager can estimate and sequence.
- Hands-on contribution. You will write code on the critical path, particularly in the early months.

Technical environment-

PostgreSQL. TypeScript and Node.js. Python. React. AWS — containerized compute, RDS, S3, IAM, CloudWatch. Infrastructure as code with Terraform or CDK. Docker. REST APIs. Message queues and event-driven processing. Redis. CI/CD. Structured logging and distributed tracing. Multi-tenant row-level security.

What we are looking for-

- 12+ years in software engineering, with at least 6 in product engineering rather than services, support, or maintenance. We will ask which years were which. We will consider a shorter career with exceptional depth; we will not consider a longer one with shallow architecture experience.
- You have designed a production system from an empty repository, not extended someone else's. Be ready to walk through its schema and explain what you would change now.
- Deep PostgreSQL: schema design, indexing strategy, query performance under load, safe migrations against large tables, transaction and isolation semantics,



and multi-tenant isolation patterns including row-level security.
- Strong TypeScript/Node.js or Python, with genuine production depth in at least one. You are still writing code.
- REST API and service boundary design, including versioning and backward compatibility.
- You have designed a state machine over a long-lived record where correctness and auditability mattered — orders, claims, approvals, tickets, ledgers, or similar.
- You have designed for concurrent editing and can explain your conflict-resolution model and its user-visible consequences.
- You have handled money in software and know why floating point is wrong for it.
- AWS in production: containerized compute, RDS, S3, IAM.
- You have integrated systems whose APIs were badly documented, unreliable, or both, and designed so their failures did not become your failures.
- You write clear technical English. Design documents are read by someone in another country who cannot ask you a quick question, and ambiguity in a document costs a sprint.

Positive to have-

- Multi-tenant B2B SaaS at scale.
- Transaction-heavy or regulated domains where correctness and audit requirements were non-negotiable.
- Event sourcing, append-only ledgers, or audit-trail-heavy designs.
- Systems in which automated or programmatic actors initiate state changes, and the boundaries you placed around what they were permitted to write.
- SOC 2 Type II technical control implementation.
- Large-scale data import and reconciliation.
- Prior experience working under external architecture review or technical due diligence.
- Experience as the senior-most technical person on a project, without a peer to defer to.

What this role is not-

Worth being explicit, because the title is used loosely across this market.

- Not a diagram-and-handover role. You will write code, review pull requests, and be accountable for what ships.
- Not a technology-selection role. Choosing a stack is a small part of it; designing the domain is most of it.
- Not a people-management role. You will mentor and set standards; the Delivery Manager owns delivery and reporting.
- Not a role for someone who has not designed a schema in three years.
- Not a role where your design goes unchallenged. Expect written review and expect to defend your reasoning.

How this role actually works-

- You write a design document. The client's principal engineer reviews it in writing, usually within two working days, and either approves it or returns specific objections. Implementation begins after approval.
- Most communication is asynchronous and written. The overlap window is for decisions that genuinely need a conversation, not for status.
- You have direct access to the client's principal engineer and to the client's chief executive. There is no account management layer between you and the decisions.
- The engagement is permanent employment with SUIPL, not a contract or deputation arrangement.

📌 Principal Engineer (Bhubaneswar)
🏢 Stabdha
📍 Bhubaneswar