Summary
A senior engineer is sought to modernize a software platform by developing new backend services and frontend applications. The role involves cloud systems, integrations, testing, and improving existing technology.
Highlights
Work on modern software architecture, cloud infrastructure, and large-scale platform modernization with flexibility and ownership.
Description
Job Type : Full-Time Salary : Based on experience Location : Gold Coast, Queensland.
Remote considered for the right person in a compatible time zone.
Who we are
Homhero makes cloud software for people who manage short term rental properties.
Booking, availability, pricing, guest messaging, cleaning, owner reporting, and the connections to channels like Booking.com, Airbnb, and VRBO all run through our platform.
We are a small team based on the Gold Coast and we love what we do.
Where the stack is, and where it is going
Right now a good part of the product runs on a legacy PHP core with a Sencha (Ext JS) frontend.
It works, it carries real traffic and it goes us to where we are now.
It is the present, not the direction.
The direction is already underway.
We have a newer engine written in NestJS and TypeScript that we are actively building out, and a React frontend taking over from Sencha.
The plan is clear: retire the PHP core, consolidate into the TypeScript engine, and modernize the frontend.
That is where you come in.
You would be building the new things while helping move what matters off the old ones.
Expect time in both, with the balance shifting toward the new stack as the work progresses.
What you would actually work on
Building out our module based engine: bookings, availability, pricing, channel management, messaging, reporting, and the public API, mostly in NestJS and TypeScriptIntegrating with third-party channels and services such as OTAs, pricing tools, and trust accounting systemsMoving functionality off the PHP core and onto NestJS, piece by piece Contributing to the React frontend as it replaces SenchaWriting tests that mean something: unit, integration, and end to end, not just one of the threeWriting the database migrations that move schema and data safely as the product changesKeeping our auto generated API documentation honest as the code changes
About
To be concrete about what sits under all of that, here is the current landscape.
Read it as a picture of the work, not a checklist you have to arrive fluent in:
Backend: NestJS and TypeScript on the new engine, PHP on the legacy coreFrontend: React for the new interface, Sencha (Ext JS) on the old oneInfrastructure: AWS, mostly Lambda and EC2, with RabbitMQ for messaging and LocalStack for running AWS services locallyData: MongoDB, MySQL, Postgres, and DynamoDB, with real migrations rather than hand edited schemas
You will not touch every one of these every week and nobody expects you to walk in knowing all of them.
It is an honest snapshot of what the job involves and what you would pick up along the way.
Infrastructure
We run a large AWS footprint today.
We are in the middle of simplifying it, cutting down the number of moving parts and we are seriously evaluating a move to colocated hardware.
If you have opinions about infrastructure and where the cloud does and does not earn its cost, you will have people to argue with.
What we are looking for
We care about what you can do and what gets you excited.
You will probably be a fit if:You are comfortable owning backend services in a typed language, and NestJS or similar Node frameworks are not foreign to youYou can read and work inside code you did not write, including PHP codeYou have integrated with third-party APIs and dealt with the mess that comes with themYou write tests because you want software to keep working, not because you need to tick a boxYou can write down how a system works so someone else can understand itYou are direct about problems and comfortable disagreeing in a technical discussion
Experience with accommodation, property management or travel systems is a bonus, not a requirement.
Tools
We use GitHub and Linear.
We embrace LLMs but make it clear the responsibility for code still lies with you.
LLMs are a tool that may help you but ultimately you need to understand each line and why itβ.
How we make the hiring decision
No whiteboard puzzles and no take home test.
Bring us code you have written and are proud of, and walk us through it.
It can be open source, a hobby project, something from past work you are allowed to share, anything real that you can talk about.
A bonus if the code is somewhat related in stack or purpose to what we do.
We want to see how you think about the code you write and the decisions behind it.
We will ask questions, so treat it as teaching us about something you already know inside out.
Expect about two calls, with a third if we need it.
The first is with the CTO.
The second is with an engineering lead.
Somewhere along the way we will show you a rough map of our current architecture so we can talk honestly about what we have now and where we want to take it.
The conversation goes both ways.
We take the probation period seriously.
There are two check-ins during it, with an honest read from both sides on how it is actually going, and at the end we make the call together.