Four people, twenty-four hours, one API contract

A hackathon team of four has a coordination problem before it has a technical one. Twenty-four hours is not enough time to discover halfway through that two people built incompatible halves of the same feature.

At Seneca Hackathon 2024 we built Housify, a real estate platform: blockchain deed verification for tamper-proof ownership records, an analysis engine for property condition and pricing, a React frontend, and the backend tying it together. I took the backend and infrastructure. Mukul took the frontend, Prabhjot the analysis engine, Jashan the smart contracts.

Four people, four separate technologies, one day. It worked, and the reason it worked had almost nothing to do with any of those technologies.

people on the team

4

separate technologies

4

hours on the clock

24

API contract holding it together

1

Agree on the seam first

Before anyone wrote implementation code, we defined the API contract. Endpoints, request shapes, response shapes, what a property object looks like, what comes back when something fails.

That took a chunk of hours that felt expensive at the time. It bought us the ability to work without talking to each other.

Once the frontend knew what GET /properties/:id would return, it could be built against that shape whether or not the backend existed yet. Once the analysis engine knew what it would receive and what it had to hand back, it was a function with a known signature rather than a negotiation. The smart contract work was the most isolated of all, since it only had to expose a way to register and verify a deed hash.

The contract was the coordination. Everything after it was four people writing code in parallel with a shared understanding of where their piece plugged in.

Integration is where hackathons die

Every hackathon I have watched fail in the last hours failed at integration. Four pieces that each work alone, none of which fit together, and no time left to reconcile them.

Defining the seam early is what converts integration from a discovery process into an assembly step. We still had problems in the final stretch, but they were the small kind: a field named slightly differently, an error case nobody had covered. Those take minutes. Discovering that two components disagree about what a property is takes hours you do not have.

Pick boundaries that match the people

The split was not arbitrary. Each person owned a piece with a clean interface and little overlap with anyone else's files.

That matters more than it sounds. Four people editing the same modules under time pressure produces merge conflicts, and merge conflicts at hour twenty are how teams lose. Ownership boundaries that follow the architecture mean people rarely touch the same file, so version control stays out of the way.

What I would keep

Some of what we built was appropriate for a hackathon and would not survive a real project. The AI analysis was a starting point rather than something anyone should trust for a purchase decision, and we said so in the demo. The blockchain component solved a genuine trust problem in a way that would need far more thought before it touched a real transaction.

The part I have kept using is the contract-first habit. Even working alone, writing down the shape of a response before implementing the endpoint tends to expose the design problem while it is still cheap to fix. It costs twenty minutes and it is the reason four people with different specialties could build one thing in a day without stepping on each other.