BFL
Build for LAWL
2026
Open Now
Four original engineering problems. Five days to build. The best submission in each domain gets an internship offer at LAWL — after a technical interview round.
We are a legal technology company building infrastructure that makes the Indian legal system accessible to people who have never had access to it. We hire engineers, designers, and builders — not through referrals or HR funnels, but through work.
Four original problems designed to be unsolvable by a coding agent alone. Each requires independent thinking, real tradeoffs, and decisions only a human engineer can justify. Your repository must be public. We read every line.
You are designing the first 5 minutes of a mobile app for a service that people desperately need but deeply distrust — think: a first visit to a doctor in a new city, filing a complaint with a government office, or consulting a financial advisor for the first time. You choose the exact context. It must be set in India. It must involve genuine anxiety, trust, and an unfamiliar process.
Your job: design the onboarding and first-action flow — from cold app open to the moment the user completes their first meaningful action. The flow must make someone want to come back tomorrow without a push notification. This is an original concept only. We will notice immediately if the information architecture, visual language, or interaction patterns are borrowed from any existing product.
You are building a webhook dispatcher service. Clients register endpoint URLs and event types they want to receive. When your service ingests an event, it fans it out to all matching registered endpoints — reliably, ordered where required, and with correct retry behaviour when endpoints fail or time out.
The difficulty is in the guarantees: at-least-once delivery, strictly ordered delivery per-subscriber for sequenced events, back-pressure handling when a downstream is slow, deduplication when a retry succeeds after the original also got through, and a delivery log that remains consistent even when your dispatcher crashes mid-fan-out. There is no off-the-shelf solution you can wrap — you build the engine.
POST /subscribe
takes a target URL, a list of event types, and an optional HMAC signing secret. Registration must be
idempotent — posting the same URL and event type twice has exactly zero side effect.POST /event
accepts { type, payload, sequence_id? }
and returns 202 immediately. Fan-out is asynchronous. The ingest endpoint must never block on delivery
latency.dead.
Log each attempt with timestamp, HTTP status, response body (truncated to 500 chars), and latency in ms.
sequence_id
must be delivered to each subscriber strictly in order. A delivery failure on event N must block event N+1
for that subscriber until N succeeds or goes dead. Out-of-order delivery is a hard failure.X-Webhook-Signature: sha256=<hmac>.
Include a standalone verification helper function in your README with a usage example.GET /deliveries?subscriber=&status=&page=
returns paginated history. POST /replay/:delivery_id
re-triggers a dead delivery as a new attempt — not a mutation of the original record.You are building a public-facing professional profile page for a person in a trust-critical profession — a doctor, chartered accountant, financial advisor, or advocate. You choose the profession. The page must feel authoritative, load progressively, and pull real live data from at least two external APIs.
You build a lightweight Express layer that orchestrates external API calls, normalises the data, and serves a single unified JSON response to your React frontend. The frontend is built from scratch — no component library, no CSS framework. Every visual element is written by hand. This is how we know you understand CSS, not just how to configure Tailwind.
You are building a multi-turn chat interface in Flutter — the kind any messaging app uses.
No Firebase. No pre-built chat SDK. No Supabase. No flutter_chat_ui,
bubble,
or any package that abstracts the chat layer. You architect the data layer, the state machine, and the UI
renderer yourself.
The interface must work correctly when the network is absent, when messages are sent in rapid succession, when the app is backgrounded mid-conversation, and when the device has never synced that conversation before. Every send must feel instant — the underlying operations can be slow, the UI must not be.
The best submission in each domain wins a paid internship at LAWL — after clearing a technical interview. No consolation prizes. No participation trophies. One winner, one offer, one interview. This is how we hire.
No cover letter. No aptitude test. Submit your GitHub repo and a walkthrough video. If your submission is the best in your domain, we reach out directly. Deadline: 1 May 2026, midnight IST.