Frequently Asked Questions

Can you work with our existing API?Yes. We are often called in to rescue an API that has drifted from its documentation or has accumulated inconsistencies over time.
How do you handle authentication and authorisation?Auth is part of the API design conversation, not a separate workstream. Authorisation rules go into the schema, not bolted on at the implementation layer.
How do you handle API versioning?We pick the versioning strategy explicitly — URL, header or GraphQL schema evolution — based on who your consumers are and how they ship code.
What about breaking changes?Breaking changes are a last resort. Most schema evolution is additive; when it is not, we run old and new in parallel with a deprecation window.
What about rate limiting and observability?Rate limits, structured logs, traces and metrics are part of the launch deliverable — when production behaves unexpectedly, you can answer why.
Who owns the API, the schema and the documentation?You do. All schemas, code, infrastructure, documentation and contract tests belong entirely to your organisation from day one.
Are your engineers on-shore or nearshore?Our team is on-shore in Australia and New Zealand. We work in your timezone, attend your standups, and overlap fully with your business hours.
Can you work alongside our existing team and our existing system?Yes — most of our work is on systems that are already in production. Slice-based modernisation is designed to coexist with the system you already have.
How big a team do you typically put on backend work?Most engagements run with one to three senior engineers plus a technical lead. We staff to the work, not to a template.
How do you handle security and data integrity?Auth, encryption, audit logging, tenant isolation and least-privilege access are part of the design conversation, not a separate workstream.
How long is a typical engagement?Discrete pieces of modernisation work run six to twelve weeks per slice. Longer engagements typically run six to twelve months.
Who owns the IP, the code and the infrastructure?You do. All code, schemas, infrastructure as code, runbooks and documentation belong entirely to your organisation from day one.
Can you audit our current frontend?Yes — often where engagements start. We measure performance on real devices, run accessibility audits, review bundle composition and write up findings.
Can you work with our existing design team?Yes. Most engagements involve an internal design team or design partner. We translate Figma into a typed, accessible component system.
Do we have to use React?No. Frontend Engineering is deliberately framework-agnostic. We work in React, Vue, Svelte, Inertia, Astro and server-rendered stacks.
How do you measure performance?Lighthouse and Core Web Vitals on the devices and networks your users actually have. Performance budgets are set up front and enforced in CI.
How does this differ from your React Development service?Frontend Engineering is the broader, framework-agnostic service. React Development is the specialist funnel for teams already on React and Inertia.
What does WCAG 2.2 AA actually mean for us?In Australia and New Zealand, WCAG 2.2 AA is the practical bar for DDA exposure, government procurement and most enterprise buyers.
Can you embed engineers into our existing team, and where are they based?Yes. Our engineers are based in Australia and New Zealand, working in your timezone — not an offshore delivery centre operating under an AU domain.
Can you upgrade our Laravel 6/7 codebase to Laravel 12?Yes. Multi-version upgrades are one of our most common engagements — we audit first, then run the work under live traffic with Pest and feature flags.
Do you work with vanilla PHP, WordPress or CodeIgniter, or only Laravel?We work with non-Laravel PHP when the goal is to modernise onto Laravel. The end goal is always a modern, maintainable application.
How modern is your Laravel stack?Laravel 12 on PHP 8.4, with Inertia, React 19, TypeScript and Tailwind v4, Octane for performance, Pest for tests, and Pulse and Telescope for observability.
Who owns the IP?You do. All Laravel code, migrations, infrastructure-as-code, schemas, tests and documentation belong entirely to your organisation from day one.
Why Laravel over Rails, Node or Django for our product?Laravel wins when you want a batteries-included framework with a deep first-party ecosystem and a senior PHP talent pool in Australia and New Zealand.
Can you embed engineers into our team?Yes. We work project-based, as a dedicated squad, or as embedded engineers in your existing team — whichever fits your situation.
Do you handle DevOps and cloud infrastructure?Yes. CI, infrastructure as code, deployment pipelines, observability and on-call runbooks are part of the deliverable, not a separate workstream.
How does Node compare to Go, Rails or Laravel for our case?Node is the right call for I/O-heavy, real-time and full-stack TypeScript work. We pick the runtime to fit the workload.
How fast can you start?Most engagements begin within one to two weeks of the initial conversation. There is no ramp-up on framework choice or project skeleton.
Who owns the code and IP?You do. All code, schemas, infrastructure definitions, documentation and tests belong entirely to your organisation from day one.
Why NestJS over plain Express?Express is a router, not an architecture. NestJS gives you modules, dependency injection, validation and a sensible default project shape.
Can you migrate us from Vue, Angular, or jQuery to React?Yes — and we strongly prefer slice-based migrations over rewrites. Big-bang frontend rewrites tend to stall, and we will say so before we quote one.
Do you build design systems as part of React work?Almost always. A real design system is the difference between an app that holds up at the tenth feature and one that needs rebuilding at the third.
Do you only build new React apps, or can you join an existing one?Both. Most engagements join an existing React codebase — we audit the patterns, learn the conventions, and start contributing PRs in the first week.
What about accessibility and performance?Both are commitments, not toggles. WCAG conformance, keyboard support, and reasonable Core Web Vitals are baseline expectations on every component we ship.
What is your stance on Next.js?It is excellent when the frontend is the product. When React sits on top of a Laravel or Node backend, Inertia usually keeps the team simpler.
Who owns the intellectual property?You do. All components, hooks, design tokens, and documentation produced during the engagement belong entirely to your organisation from day one.
Can we hire augmented engineers permanently?Permanent hiring of augmented engineers is possible and discussed on a case-by-case basis to find the best outcome for everyone involved.
How is team augmentation different from outsourcing?Team augmentation embeds engineers directly into your team under your direction, while outsourcing hands off an entire project to an external provider.
How quickly can augmented engineers start?Most team augmentation engagements begin within one to two weeks of the initial conversation, with vetted engineers ready to deploy.
What about timezone alignment for augmented teams?Augmented engineers operate across Australian and New Zealand timezones by default, with overlap during core working hours for distributed teams.
What happens when a team augmentation engagement ends?Knowledge transfer is built in - documentation, pair programming and clean handoffs so your team has no gaps when augmented engineers step away.
Who owns the intellectual property from augmented engineers?All code, documentation, and work product created during a team augmentation engagement belongs entirely to your organisation from day one.
What is custom software development?Engineering-driven process of building tailored software for unique business needs — scalable, flexible systems that off-the-shelf software cannot match.