Tips & Advice

Before the Day

Set up your repo immediately

Create your GitHub/GitLab repo at <time?> and make your first commit before you write a single line of application code. Commit your initial project structure, .gitignore, .env.example, and docker-compose.yml skeleton.

The AI scan checks your commit history. One commit at <time?> is a red flag.

Agree on your stack in the first 15 minutes

Don’t spend an hour debating frameworks. Pick what your team knows best. A well-implemented app in familiar technology will beat a half-finished one in a shiny stack every time.

Assign ownership early

Suggested split for a 4-person team:

1 person — auth, user system, database schema
1 person — core business logic + tests
1 person — frontend (main views, data visualisation)
1 person — DevOps (Docker, CI, deployment) + documentation

Put your strongest backend developer on the core business logic. That’s what gets scrutinised most.

During the Day

Build the core logic first

Everything else depends on it. Get the core business logic working and tested before you build the frontend. A polished UI on broken logic scores poorly.

Commit constantly

Every feature, every fix, every meaningful change. Small commits are better than large ones. Use conventional commit messages (feat:, fix:, test:, docs:).

Wrap multi-step operations in database transactions

The single most common critical issue in the AI scan: operations that touch multiple database rows are not wrapped in a database transaction. If the server crashes between steps, you get inconsistency. Use a transaction.

BEGIN;
UPDATE accounts SET value = value - :amount WHERE id = :accountId AND value >= :amount;
INSERT INTO records (account_id, value, ...) VALUES (...);
COMMIT;

Validate all input

Every API endpoint that accepts user input should validate it before it touches the database or business logic. Check types, ranges, and state preconditions (e.g. “is this operation currently allowed?”).

Write tests as you go

Don’t leave tests for the end. Write them alongside the core logic. You’ll catch bugs earlier and have better coverage by <time?>.

The Last Hour (<time_range?>)

Stop adding features at 16:00

Stop adding features at <time?>. Use the last hour for:

Fixing any remaining bugs in core functionality
Running your full test suite
Verifying docker compose up works from a clean clone
Finalising documentation (README, decision log, known issues)
Final push and deployment check

The decision log is worth points

Write it. It takes 10 minutes and judges notice when it’s missing. Include:

What technical approach you chose for the core requirement and why
What you descoped and why
What you’d do differently with more time
Known issues and limitations

Check for hardcoded secrets

Before your final push, grep your codebase for anything that looks like a password, API key, or secret. Move it to .env and add it to .env.example.

grep -r "password" --include="*.js" .
grep -r "secret" --include="*.js" .
grep -r "api_key" --include="*.py" .

The Demo

Show the full end-to-end flow

Your 5-minute demo should walk through the complete user journey — from registration through the core business logic to the final output. Make it live, not a slides deck.

Let the audience interact

If you have time, let the audience actually use your app during the demo. This is the highest-scoring thing you can do in the Product & Demo category.

Know your decisions

Be ready to answer:

“Why did you choose this approach for the core feature?”
“What happens if two users perform conflicting operations simultaneously?”
“How do you prevent invalid state in your data model?”
“What would you do differently with more time?”

Common Mistakes to Avoid

Spending too long on the frontend before the backend works
Picking a complex implementation when your team doesn’t fully understand it
No database transactions on multi-step operations
One giant commit at <time?>
Hardcoded credentials in docker-compose.yml
No tests — even 5 good tests are better than none
Skipping the decision log — it’s 10 minutes of writing worth real points
Not testing docker compose up from a clean clone before freeze