Humble
A content platform for founders, pairing vetted entrepreneurial advice with mental-health resources and a discounted marketplace of startup tools.
View case study , HumbleCase study · Event discovery
A personalised feed of tech events from around the world, where the engineering problem turned out to be relevance at speed on a database not built for it.
Delivered · Handed over
01The business situation
Tech events are scattered across conference sites, meetup listings and social posts, and no single view of them exists. The founder, Rakesh Ranjan (a YC ’18 graduate and IT industry veteran, already committed to an MVP approach) wanted to test one thing: whether a curated, personalised feed would earn enough engagement to justify a product. That meant the platform had to feel useful before anyone signed up.
Core challenge
Make a large, messy corpus of worldwide events searchable and personally relevant, fast, and without forcing a login first.
Before
Events scattered across sites, feeds and word of mouth
After
One personalised, searchable view of what is happening
EventsDF Platform
02The system at a glance
03Workflow 01
The feed is open. A visitor can browse recommendations and trending events without an account, because asking for registration before demonstrating value is how a discovery product dies.
assets/portfolio/eventsdf/workflow-feed.png · 16 / 11
04Workflow 02
Search had to rank a large corpus meaningfully and return fast. The chosen database made that harder than expected, and the fix was a hand-tuned query rather than a change of architecture.
1Keyword search
assets/portfolio/eventsdf/step-search.png · 1 / 2.04
2Ranked results
assets/portfolio/eventsdf/step-results.png · 1 / 2.04
3Event detail
assets/portfolio/eventsdf/step-detail.png · 1 / 2.04
05Workflow 03
Alongside each event the platform collects the relevant social chatter, which is often where the actual signal about whether something is worth attending lives.
assets/portfolio/eventsdf/social-context.png · 16 / 10
assets/portfolio/eventsdf/preferences.png · 1 / 2.04
06Engineering behind the product
A conventional stack with one genuinely awkward problem in the middle of it, solved by understanding the database rather than replacing it.
Search was built on the database’s own full-text capability to meet the timeline, accepting it as an interim step toward a dedicated engine.
The ORM could not express the ranking the product needed, so the query was written directly to balance relevance against speed on a large corpus.
Recommendations are shaped by declared interests and skill level rather than by popularity alone.
Lists and recommendations are reachable without authentication, which was a deliberate product decision with caching implications.
Curation and periodic work run through a task queue outside the request cycle.
Sign-in runs through several established identity providers.
Public forms are protected against automated abuse across all their entry points.
07Technical architecture
A Django platform whose relevance ranking was hand-written against MySQL full-text search to meet the MVP timeline.
Backend
Frontend
Data & search
Async
Integrations
08Delivery journey
Agree the features that test the idea
Client-supplied designs, extended by us
A small backend and frontend team
Agile scrum against a defined backlog
Validate before release
Ship with the feature set agreed
Transition the project to the client
Two phases were delivered. After a stable second phase the client chose to continue development in-house, and we supported the transition. Dates and durations are withheld until confirmed. Verify before publishing
09What the system enabled