Decoded

Decoded shows renters how a potential home connects the blocks that make up their world, from work and study to friends, culture, routines, and essential resources.

Comment

Inspiration

The places we live are some of the most important blocks that make up our world.

Where we live determines far more than our bedroom, rent, or postcode.

It affects whether we can get to university, make it to work, see our friends and family, exercise, participate in our communities, and still have enough time left in the week actually to live our lives.

Yet rental platforms mostly tell us what a property is.

They tell us the number of bedrooms and bathrooms, the weekly rent, photos, and maybe how far it is from the nearest station.

They do not answer the much more important question:

What will my life actually look like if I live here?

That led us to Decoded.

Our project responds to the SYNCS HACK 2026 theme:

Blocks That Make Up The World

We see a home as one of the most important blocks in someone's world, but its value depends on how well it connects to all the other blocks that make up that person's life.

University might be one block.

Work might be another.

Friends, family, the gym, regular activities, community spaces, and other important destinations might be others.

A rental can look perfect on paper and still be completely wrong for the person considering it.

Two people can inspect the same property and have completely different experiences living there because their routines, priorities, and tolerances are different.

That is the problem Decoded is designed to solve.

Rental sites tell you what the property is. Decoded tells you what your life there could be like.

Our core idea became:

Decode your life before you sign.

What it does

Decoded turns a prospective rental address into a personalised decision report.

Instead of judging a property against a generic idea of a "good suburb", Decoded asks the renter about the blocks that make up their own world.

The renter enters:

  • a potential home;
  • the destinations that regularly matter to them;
  • how many times they visit each destination each week; and
  • the maximum one-way journey they personally consider reasonable.

The hackathon prototype supports up to four regular destinations.

Those destinations might include:

  • university;
  • work;
  • the gym;
  • a partner's home;
  • family;
  • friends;
  • regular activities;
  • any other place that regularly shapes the renter's week.

Decoded then uses real Transport for NSW journey information to analyse how well the potential address supports that routine.

The result is not an unexplained suburb rating.

It is an evidence-led answer to a personal question:

Does this exact address work for this person's life?

Accessibility is personal

One of the most important ideas behind Decoded is that accessibility is not universal.

A 35-minute commute might be completely reasonable for someone travelling twice per week.

The same commute might be exhausting for someone travelling five days per week.

That means travel time alone is not enough.

Frequency matters.

Personal tolerance matters.

The destination's purpose matters to the renter.

That is why Decoded does not try to decide what everybody should value.

The user tells us what matters. We measure access to it.

Two people can analyse the same apartment and receive different conclusions because their lives are different.

We think that is much more useful than pretending there is one universal definition of a good location.

It also avoids inferring people's priorities from demographics.

Decoded asks users directly what belongs in their world.

LifeRadius

One of our core concepts is LifeRadius.

LifeRadius looks beyond the property itself and asks how the address connects to the destinations that repeatedly make up someone's week.

For every regular destination, Decoded considers information such as:

  • one-way journey time;
  • visit frequency;
  • walking time;
  • walking distance where available;
  • transfers;
  • transport mode;
  • the renter's own maximum acceptable journey time.

Decoded then turns those individual journeys into a picture of the renter's weekly life.

This lets us ask a much more meaningful question than:

"How far away is work?"

Instead, Decoded can ask:

How much of my week will living here cost me in travel?

A 30-minute journey made four times per week has a very different impact from a 45-minute journey made once.

LifeRadius makes that difference visible.

Routine Fit

The headline result in Decoded is Routine Fit.

There is no universal definition of a good commute, so we do not invent one.

Instead, every destination is compared against the renter's own chosen one-way travel limit.

Routine Fit then calculates the proportion of that person's regular weekly destination visits that fall within those limits.

Importantly, the result is frequency-weighted.

That means a destination visited five times each week contributes more to the result than somewhere visited once.

For example, rather than presenting an unexplained result such as:

This property scores 78/100.

Decoded can explain something concrete:

9 of your 13 regular weekly destination visits fall within the travel limits you selected.

The user can see:

  • what their limits were;
  • which journeys passed;
  • which journeys exceeded them;
  • how frequently those journeys occur; and
  • exactly why the final Routine Fit was produced.

Routine Fit is therefore deterministic and explainable.

It is not an opaque AI-generated lifestyle score.

Weekly travel burden

A journey can look harmless when viewed once.

When repeated across an entire week, it can become one of the highest hidden costs for a location.

Decoded calculates an estimated weekly return-travel burden for the renter's regular destinations.

For example, if a journey takes 20 minutes one way and happens three times each week, Decoded accounts for both the outward and return journey across those visits.

The report can then show:

  • total estimated weekly travel;
  • each destination's contribution to that total;
  • which journey creates the largest weekly commitment; and
  • how the renter's travel time is distributed across their routine.

This became one of the most useful parts of the product.

A rental that appears cheaper may quietly cost several additional hours every week.

Decoded makes that trade-off visible before someone signs the lease.

Explainability

Explainability became one of our most important design principles.

Housing is a high-stakes decision.

If a product assigns a score to someone, the user should be able to understand where that score came from.

Decoded therefore includes a Why this score explanation alongside Routine Fit.

The report exposes:

  • visits per week;
  • the renter's selected limits;
  • journey durations;
  • whether each journey fits;
  • weekly travel burden;
  • how much each destination contributes to the renter's week.

The report also contains deterministic insights that explain important trade-offs.

For example, Decoded can identify which destination represents the renter's largest travel commitment and explain what percentage of total weekly travel it accounts for.

The objective is not to tell the renter what decision to make.

It is to give them enough evidence to make that decision themselves.

TimeLens

Access also changes with time.

A route that looks convenient at one moment may behave differently at another point in someone's real routine.

That led us to TimeLens.

TimeLens compares representative travel periods for selected destinations.

For the hackathon prototype, Decoded can compare representative morning and evening journey times.

Instead of assuming that one journey-planner result represents every possible trip, the renter can see additional context around when they are likely to travel.

For example, the report might show that the same university journey takes a similar amount of time in the morning and evening — or reveal that one period is noticeably worse.

A map may tell you two places are geographically close.

Decoded tries to tell you whether they are practically accessible when you actually need them.

ShadowCommute

Travel time alone can also hide route complexity.

A 30-minute direct journey is not necessarily equivalent to a 30-minute journey involving several transfers, significant walking, or poor alternatives.

That led us to ShadowCommute.

ShadowCommute describes route complexity and resilience using transparent factors such as:

  • transfers;
  • walking burden;
  • journey characteristics;
  • and whether useful backup-route information is available.

It is deliberately framed as:

Route resilience, not a disruption prediction.

ShadowCommute does not claim that a train will fail tomorrow or that a particular commute will definitely become unreliable.

Instead, it surfaces characteristics of the route that a single travel-time number can hide.

That reflects a broader principle we followed throughout Decoded:

Show what the available evidence supports, and clearly label what it does not.

Real Transport for NSW analysis

The hackathon version of Decoded integrates with Transport for NSW journey-planning data.

This allowed us to prove the product using real Sydney journeys rather than only mocked routes.

It also became one of our biggest engineering challenges.

Real provider responses did not always behave like simplified test fixtures.

During development, we discovered issues including:

  • street addresses being returned using provider-specific location types;
  • different location selectors being required by the Trip Planner;
  • live journeys sometimes omitting a top-level journey duration;
  • walking legs being represented using the provider-specific value footpath;
  • and provider-specific transport information needing to be separated cleanly from Decoded's own product model.

Instead of working around these issues in the frontend, we improved the provider layer.

For example, when TfNSW omitted a summary journey duration, Decoded derived it from the durations of the individual journey legs.

When TfNSW returned walking segments as footpath, we normalised those into walking rather than exposing that provider-specific concept to the rest of the application.

We then added regression tests for the real response behaviours we encountered.

That work was important because we wanted the hackathon demo to represent a genuine working integration rather than an interface designed only around idealised fixtures.

How we built it

Decoded is a modular web application built using:

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Transport for NSW APIs
  • BOCSAR data integration
  • NSW spatial services
  • Vercel

One of our main architectural decisions was to prevent external API formats from dictating the product's structure.

The architecture follows this pipeline:

External APIs
→ provider adapters
→ Decoded-owned normalised domain models
→ deterministic analysis and insight engine
→ report UI

Transport for NSW responses are handled inside the provider layer.

They are converted into Decoded's own normalised route models before reaching our analysis engine.

The frontend therefore never needs to understand raw provider responses.

This separation gives us several benefits:

  • provider-specific behaviour remains isolated;
  • analysis logic remains deterministic and testable;
  • the UI consumes stable Decoded-owned contracts;
  • provider failures can be represented explicitly;
  • optional modules can fail independently;
  • additional providers could be integrated later without rewriting the entire product.

Partial failure handling

Working with live external data also forced us to think about failure as part of the product rather than just an error state.

If a renter submits multiple destinations and one route cannot be analysed, Decoded does not discard all successful results.

Instead, it supports a partial report.

Successful destinations remain visible.

The failed destination is identified separately.

If every route fails, Decoded does not pretend that the renter has zero travel burden or generate a fake Routine Fit.

Instead, the report explicitly communicates that no route could be assessed.

Routine Fit becomes unavailable.

Failed destinations remain visible.

Optional modules such as TimeLens and ShadowCommute explain that they could not run.

The distinction matters:

A zero-minute journey and an unknown journey are not the same thing.

We wanted Decoded to remain honest about that.

Saved demo fallback

Because the product relies on a live external transport provider, we also built a saved TfNSW demo snapshot.

The saved routine contains three destinations:

  • University;
  • Part-time work;
  • Gym.

It produces a complete Decoded report including:

  • Routine Fit;
  • weekly travel burden;
  • regular journeys;
  • TimeLens;
  • ShadowCommute;
  • deterministic insights.

The saved report is explicitly labelled as saved data.

It is never presented as current live transport data.

This means the complete experience can still be demonstrated if the external provider becomes unavailable during judging, without pretending that saved information is live.

For us, that transparency is part of the product rather than something to hide.

Safety Context

We also explored how housing decisions can use safety-related information without turning uncertain data into an unsupported prediction.

A label such as:

"This suburb is safe"

would be misleading.

Recorded incidents generally describe broad areas.

They do not tell us what a specific person will experience at a specific dwelling.

Decoded therefore treats this as Safety Context, not a safety score.

The architecture can combine source-labelled information such as:

  • official broad-area context where available;
  • supported property security facts;
  • relevant descriptions of the renter's route or routine.

The backend includes integration work for official BOCSAR data and NSW geographic context.

However, Decoded deliberately avoids producing a simplistic safe/unsafe score or crime probability.

Where sufficient information is unavailable, the report says so.

The principle is:

Provide evidence and context without converting uncertainty into false certainty.

This module also remains separate from Routine Fit because transport accessibility and recorded area incidents are fundamentally different kinds of information.

Honest module availability

Another feature we built is explicit module availability.

Different sections of an address analysis may have different data requirements.

Decoded can represent states including:

  • available;
  • partially available;
  • unavailable;
  • not requested;
  • not enabled.

For example:

  • if TimeLens was not requested, the report can say that;
  • if routing fails, ShadowCommute can explain why it is unavailable;
  • if Everyday Access has not been enabled, the product says so;
  • if Safety Context lacks the required geographic information, the report does not fabricate a result.

This allows the core report to remain useful even when optional analysis modules cannot run.

Challenges we ran into

One of the hardest product questions was:

What does it actually mean for an address to be a good fit?

The answer is different for everyone.

It would have been much easier to invent one generic neighbourhood score.

But that would hide assumptions and create a false sense of precision.

Instead, we designed Decoded around explicit user choices:

  • where they regularly go;
  • how often they go there;
  • how much travel they personally tolerate.

The second major challenge was making the product explainable.

We did not want Routine Fit to become another mysterious number.

That led us to frequency-weighted calculations, Why this score, weekly travel burden, and route-level evidence.

Another major challenge was integrating real TfNSW data.

Testing against live Sydney journeys exposed response shapes and provider behaviours that simplified fixtures did not reveal.

We had to debug issues involving:

  • location types;
  • Trip Planner compatibility;
  • missing journey durations;
  • walking-leg classification;
  • real API failure behaviour.

Those issues ultimately improved the architecture by reinforcing the importance of keeping provider-specific data behind a normalisation boundary.

We also had to avoid feature fragmentation.

The larger Decoded idea could include transport, groceries, community resources, safety, healthcare, listing data, environmental information, and many other signals.

That could easily become a collection of unrelated statistics.

We therefore kept returning to one rule:

What does this information mean for this person's life at this address?

If something did not strengthen that core decision during the hackathon, we deferred it.

Accomplishments that we're proud of

We are most proud of changing the unit of analysis.

Traditional property search starts with the house.

Decoded starts with the person.

Instead of:

Is this property near a station?

we ask:

Can this address connect you to the blocks that make up your world?

Instead of:

Is this commute generally reasonable?

We ask:

Does this journey fit the limit you personally selected, and how often does it affect your week?

Instead of:

Is this generally a good suburb?

We ask:

Does this exact address work for your life?

We are also proud that the final prototype is genuinely functional.

The application supports:

  • prospective property entry;
  • one to four personal destinations;
  • independent visit frequencies;
  • independent one-way travel tolerances;
  • routine presets;
  • live Transport for NSW routing;
  • walking and transfer analysis;
  • frequency-weighted Routine Fit;
  • weekly return-travel burden;
  • Why this score explainability;
  • Where your week goes visualisation;
  • LifeRadius journey breakdowns;
  • TimeLens representative-time comparisons;
  • ShadowCommute route-resilience context;
  • deterministic insights;
  • partial-route failure handling;
  • complete failure handling;
  • explicit optional-module states;
  • Safety Context architecture;
  • saved-demo fallback;
  • editable review and report flows.

We tested the final rendered application end-to-end using live transport data rather than relying only on unit tests.

A verified live example between Newtown and the University of Sydney successfully produced a real journey, walking data, zero failed anchors, weekly travel burden, and a 100% Routine Fit against the renter's selected limit.

The final engineering baseline also passed our automated test suite, TypeScript validation, linting, and production build checks.

What we learned

The first thing we learned is that:

Distance and accessibility are not the same thing.

A destination can be geographically close but practically inconvenient because of:

  • transport schedules;
  • transfers;
  • walking;
  • frequency;
  • the time of day;
  • the renter's own tolerance.

We also learned that frequency changes the meaning of travel time.

A route does not have one cost.

Its real cost depends partly on how often it becomes part of someone's life.

We learned that personalisation works best when people directly express what matters to them rather than when software attempts to infer their preferences from demographic information.

We learned that live provider integrations require defensive engineering.

Real APIs contain irregularities that polished sample responses do not always reveal.

And we learned that information that is unavailable should remain unavailable.

Trying to fill every empty section with a number can make a product appear more complete while making it less trustworthy.

Most importantly, we learned to think differently about an address.

An address is not just a point on a map.

It is a connection point between many of the blocks that make up someone's world.

What's next for Decoded

Our hackathon prototype focused on proving the core personalised address-analysis experience end-to-end.

There were several ideas in our original vision that we deliberately did not rush into the MVP.

These now form the next stage of Decoded.

Everyday Access

A future version could analyse access to user-selected everyday resources such as:

  • supermarkets;
  • pharmacies;
  • healthcare;
  • parks;
  • childcare;
  • cafes;
  • restaurants;
  • gyms;
  • other regular services.

The important difference from a generic amenity score would remain the same:

The user chooses what actually matters to them.

Rather than counting every supermarket nearby, a renter could specify the places or types of services they actually rely on.

Community and Culture Access

We also want to extend the same model to community and cultural resources.

A renter might care about:

  • community organisations;
  • places of worship;
  • cultural centres;
  • particular grocery stores;
  • particular food communities;
  • social groups;
  • family networks.

These preferences should never be inferred from someone's ethnicity or demographic profile.

The renter should explicitly choose the resources that belong in their world.

Decoded could then analyse their access.

Richer Safety Context

The current prototype establishes the architecture for source-labelled Safety Context.

Future work could expand this using:

  • additional official datasets;
  • more granular geographic context where statistically appropriate;
  • clearer explanations of area-level versus dwelling-level information;
  • optional renter-supplied property characteristics;
  • richer routine context.

We would continue avoiding simplistic safe/unsafe scores.

Dwelling and security characteristics

A future renter could optionally enter facts such as:

  • apartment versus detached house;
  • controlled building access;
  • intercom;
  • secure parking;
  • building entry configuration;
  • floor level;
  • supported security features.

These could provide additional factual context without claiming to predict whether an incident will occur.

Rental listing ingestion

The current MVP begins with manual address entry.

A future version could accept a property listing URL and extract the supported information from it.

That could allow the experience to begin with:

"I found this rental."

and immediately move into:

"Decode what my life would look like here."

Screenshot extraction

We also considered screenshot-based listing ingestion.

A user could upload screenshots of a rental listing, and Decoded could extract supported information such as:

  • address;
  • rent;
  • property type;
  • bedrooms;
  • selected listing details.

The renter would confirm extracted information before it was used.

This was deliberately deferred from the hackathon so we could prioritise the core analysis experience.

Property comparison

The hackathon prototype analyses one prospective home at a time.

That was intentional:

one property → one routine → one explainable report.

A future version could compare several prospective rentals using the same saved routine.

For example, comparison could show:

  • Routine Fit;
  • weekly travel burden;
  • major destination trade-offs;
  • TimeLens differences;
  • route complexity;
  • Everyday Access;
  • relevant contextual information.

We would still avoid producing an unexplained "best property" score.

Maps and LifeRadius visualisation

A future report could make LifeRadius both spatial and numerical.

Potential additions include:

  • route maps;
  • walking segments;
  • interchange points;
  • destination clusters;
  • a visual representation of the user's weekly world around the property.

This would visually reinforce the Blocks That Make Up The World concept.

Saved user routines

Eventually, users could save their routine once.

Instead of repeatedly entering university, work, family, or other important destinations, the renter could maintain a personal life profile.

They could then analyse every new property against that same routine.

The workflow could become:

Save your life once. Decode every property against it.

More cities and providers

Because external provider responses are normalised behind Decoded's own domain model, the longer-term product does not have to remain NSW-only.

Additional transport providers could eventually be integrated while preserving the same:

  • Routine Fit model;
  • weekly travel calculations;
  • TimeLens;
  • report structure;
  • personalised decision experience.

Property discovery

Longer-term, Decoded could move beyond analysing a property that the renter has already found.

A renter could define:

  • their important destinations;
  • their travel limits;
  • their budget;
  • their property requirements.

Decoded could then help identify areas or rentals that align with their current lifestyle.

That is deliberately beyond the scope of this hackathon prototype, but the personalised analysis engine provides a foundation for it.

Why we chose this scope

Our original concept was much broader than the final hackathon build.

We could have attempted to transport, provide groceries, access healthcare, explore culture, ensure safety, list extraction, property comparison, and discovery all at once.

Instead, we chose to prove one complete vertical slice.

The final prototype demonstrates:

Potential property
→ personal routine
→ real transport data
→ provider normalisation
→ deterministic analysis
→ Routine Fit
→ weekly travel burden
→ explainability
→ TimeLens
→ ShadowCommute
→ personalised report
→ rental decision.

That core experience works.

Everything in the future roadmap strengthens the same idea rather than replacing it.

Impact

Housing decisions have unusually high switching costs.

If someone chooses a café they do not like, they can go somewhere else tomorrow.

If someone signs a lease and only later discovers that the location makes their routine exhausting, that decision can affect them for months.

People currently make these decisions using incomplete and fragmented information.

Decoded tries to move that discovery earlier.

Before signing, a renter should be able to understand:

  • how much time a location may consume every week;
  • which journeys create the biggest trade-offs;
  • which regular destinations fit their personal limits;
  • how representative travel times differ;
  • where route complexity exists;
  • where information is uncertain or unavailable.

Decoded does not make the housing decision for the renter.

It gives them better evidence with which to make that decision themselves.

What makes Decoded different

Decoded is not another rental-listing platform.

It is not a suburb ranking.

It is not a generic liveability score.

It is not an AI system inventing a recommendation from hidden assumptions.

It is a personalised decision layer between finding a rental and signing for it.

The renter defines:

  • the property;
  • the destinations;
  • the frequency;
  • the tolerances.

Decoded provides:

  • the journey evidence;
  • the calculations;
  • the trade-offs;
  • the explanation.

That distinction is the core of the product.

Final vision

We started with a simple observation:

Where you live changes how the rest of your world fits together.

Housing connects to education.

Housing connects to employment.

Housing connects to relationships.

Housing connects to community.

Housing connects to health.

Housing connects to time.

Those are the blocks that make up a person's world.

Decoded's long-term goal is to make those connections visible before somebody commits to a home.

The hackathon prototype begins with the part we could make immediately measurable and useful: the renter's routine and the journeys connecting it to a prospective address.

From there, the same personalised model can expand into everyday resources, community and cultural access, richer contextual information, listing ingestion, property comparison, and eventually property discovery.

But the principle remains the same:

Start with the person's life, then decode how well an address supports it.

Decoded helps renters understand whether a potential home fits the life they already have before they sign the lease.

Decode your life before you sign.

Built With

Share this project:

Updates