The H0 hackathon happens to be the second hackathon I would be participating in and it's been an exciting one and that's why I decided to share my experience here in detail from the innovation stage up to the product stage.
The entire goal of this hackathon is to build any fullstack application using any one of AWS databases (Amazon Aurora PostgreSQL, Aurora DSQL, or DynamoDB) and Vercel's V0 or deploying your app on vercel and my team and I used the opportunity to build an application targeted towards students to help solve a problem we also face as students.
Problem statement
Many students are either too shy or haven't really participated in public speaking and there comes a stage usually in the final year when they have to defend project, present thesis or even handle oral examinations. Confidence and clarity during these presentations actually count for a lot and because of lack of preparation before they are faced with reality, they tend to score poorly.
Solution
With the afore mentioned problem, we came up with a solution that creates a simulation environment for students to actually practice different scenarios with AI powered panelists that give them an experience close to what they will be facing in reality. This solution is what brought about Simustratum
System design
After brain storming on the idea and we were set to go, the next step was to take a deep dive into the technologies we were using and why we were using them and this was affected by the tools we have worked with in the past and were comfortable working with.
Tech stack
- Nextjs (frontend)
- Fastapi (Backend)
- Aurora Postgresql (Database)
- AWS EC2 (Backend hosting)
- Nginx (Reverse proxy)
- Duck DNS (Server Domain name)
- Git (Version control)
- Cloudinary (Blob storage)
- Github Actions (CI/CD pipeline)
- Anthropic API (Fallback LLM)
- Google Gemini (Default LLM)
- Qdrant Cloud (RAG)
Why use Aurora Postgresql over Aurora DSQL and Dynamodb?
Relational data model fits perfectly. Simustratum has deeply connected data — users own sessions, sessions have transcript turns, turns reference specific panelists, scores update per turn. That's a join-heavy, foreign-key-enforced relational structure. Aurora PostgreSQL handles this natively. DynamoDB would have required redesigning the entire data model around key-value access patterns. Read more here
JSONB for panelist configs. The
Session.panelistscolumn stores flexible panelist data (name, role, strict, inquisitive, id) as a JSONB blob — queryable, indexable, and schema-flexible without a separate table. This is a PostgreSQL-native feature. DynamoDB also stores JSON but without SQL operators to query inside it, and Aurora DSQL has more limited JSONB support than standard Aurora PostgreSQL. AWS migration playbookACID transactions protect transcript integrity. Every session turn requires writing a
TranscriptTurnrow AND updating the parentSessionscores atomically — either both commit or neither does. Aurora PostgreSQL's full ACID guarantees mean your turn sequence is always consistent and replay always gets a gapless ordered record. DynamoDB's transactions are limited to 100 unique items per write. DynamoDB's Contraint DynamoDB's TransactionsThe feedback report needs analytical SQL. Features like "show my clarity score trend across all my defense sessions" or "which panelist asked the most follow-up questions" are window functions and multi-table aggregations. In Aurora PostgreSQL that's a single SQL query. In DynamoDB it would require exporting data to Athena or Redshift — real additional infrastructure. Aurora DSQL would handle the queries but is overkill for a single-region app and is too new to have the production track record Aurora PostgreSQL has.
It would be easier for developers to contribute to by quickly spinning up their local postgresql server; Aurora has full postgresql support
Problems we encountered
I would say development was quite smooth, most of the issues we faced while building happened when we decided to go live (Still not fully resolved yet); having to work with AWS services for the first time; setting up EC2 instance for the backend and running nginx. The major issue I would say was setting up the Aurora postgresql server on AWS - Took us about 4 tries to do cause we weren't sure we were setting up the right db but we were all along.
What's next?
Next step will be wrapping up our submission and see how it goes from there. Here is the live url for those who want to try Simustratum out
