Last Saturday, we hosted the first edition of the H.M.F Hardware Workshop with one simple goal: teach people the fundamentals of hardware and help them build their first hardware device from scratch. We also invited founders, builders, and hardware enthusiasts to showcase the projects they had been working on and share their experiences.

The workshop started as a small experiment.

We had limited space and wanted to run a pilot workshop to understand the demand, learn what worked, and identify what could be improved for future editions.

To kick things off, we posted a tweet to gather a small community of hardware enthusiasts.

The response was far beyond anything we expected.

The tweet received over 200,000 views, 6,000+ likes, and attracted more than 300 people to the community within the first two hours. We also had over 800 people waiting to join.

Our goal was to keep conversations focused on hardware and create a space where builders could comfortably ask questions, share knowledge, and help each other.

Soon after, we announced our first hardware workshop in partnership with Ravi Pujari from Craftech.

Everything was planned and executed within just four days.

Despite receiving more than 400 applications, we only had room for 30 participants. In the end, we stretched the capacity and accommodated over 40 people.

The objective was simple: help participants build their first hardware project and guide them through creating their own Tamagotchi-style device.

Alongside the workshop, attendees got hands-on access to projects they would normally only see online. Kinetic displays, hardware prototypes, custom devices, and even a Industrial robotic arm.

Kicking Off the Day

The workshop began at 10:00 AM with registration and kit distribution. But we wanted to make the experience memorable from the moment people walked in.

For registrations, we used a robotic arm that greeted attendees as they checked in and automatically printed their name tags. For many participants, it was their first time interacting with a real-world robotics system up close, and it immediately set the tone for the day ahead.

Instead of a standard registration desk, attendees were welcomed by a piece of hardware doing actual work something that perfectly reflected the spirit of the workshop and what we hoped to inspire people to build themselves.

We began with the fundamentals of hardware development, covering everything from electronic components and circuit design to prototyping and programming. Every participant received a hardware kit that they could use throughout the workshop and take home afterward.

The first half of the session focused on building a strong foundation. We walked through every component step-by-step, explaining what it does, how it works, how to connect it correctly, and how to program it.

To make the learning process easier, we built a custom web-based simulation tool that helped participants understand breadboard layouts, wiring, and circuit connections before touching the physical hardware. You can check the website out here: gochi.in

The simulator allowed builders to visualise where each wire should go and understand how different sections of a breadboard function. This significantly eased the learning curve for first-time hardware builders.

Building the First Prototype

Once the fundamentals were covered, participants moved on to assembling their first working device using the kits we provided.

Watching people go from knowing almost nothing about hardware in the morning to successfully wiring and programming a working project by the afternoon was incredibly rewarding.

After a short lunch break, the workshop shifted from guided learning to open experimentation.

At this point, it wasn't about following instructions anymore it was about imagination. Participants started combining sensors, writing custom code, experimenting with AI tools, and building projects beyond the original Tamagotchi concept. The room transformed into a playground for rapid prototyping and creativity.

The results were incredible.

One participant built an AI-powered question-answering device. Another created a voice assistant inspired by Rocky from Project Hail Mary. Others experimented with custom sensors, displays, and interactive hardware experiences.

What started as a small workshop quickly became a room full of people building, learning, collaborating, and discovering how accessible hardware development can be.

The Hardware Showcase

As participants continued building and experimenting with their projects, we also hosted a Hardware Showcase featuring founders, builders, and teams working on real hardware products and companies.

The showcase gave attendees an opportunity to see what building hardware looks like beyond prototypes and tutorials. Founders presented the products they were working on, shared their journeys, and gave everyone a closer look at the challenges and opportunities involved in building hardware companies.

Alongside the founder showcases, several independent builders brought projects they had been working on for months and, in some cases, years. Attendees got to interact with custom-built devices, robotics projects, and hardware experiments that they would rarely get a chance to see in person.

From robotic arms and automation projects to custom electronics and experimental builds, the showcase became one of the most inspiring parts of the day. It gave newer builders a glimpse into what is possible when curiosity turns into consistent building.

More importantly, it created conversations between beginners and experienced builders, making the workshop feel less like a classroom and more like a gathering of people passionate about building things.

Wrapping Up with a DJ Sundowner

After a full day of learning, building, and showcasing projects, we wanted to end the event on a different note.

To conclude the workshop, we hosted a DJ Sundowner with the help of DJ Amog. What started as a hardware workshop quickly turned into an evening of conversations, networking, music, and celebration.

Builders who had spent the entire day soldering, coding, debugging, and prototyping finally got a chance to relax and connect with each other. Founders, first-time builders, engineers, and enthusiasts all came together to share ideas, discuss future projects, and reflect on everything they had built throughout the day.

With over 60 people on the floor and an incredible atmosphere throughout the evening, it was the perfect way to close out the first edition of the H.M.F Hardware Workshop.

What's Next?

We’re already planning the next edition of the H.M.F Hardware Workshop and will be announcing it soon for next month. The next version will build on everything we learned from this event, with more capacity, more projects, more showcases, and even more opportunities for builders to collaborate.

Beyond workshops, we’re also working on a number of initiatives designed to support the hardware ecosystem from community gatherings and founder showcases to hands-on build sessions and larger-scale events. This workshop was just the first step in a much larger vision.

If you’d like to be part of the community and stay updated on future workshops, events, and opportunities, you can join us here: The Hardware Community

We’re excited about what’s ahead and look forward to building the next chapter of the hardware community together.

This is just the beginning.

The hackathon landscape is changing, we are seeing projects getting shipped faster than ever, to accommodate this speed, we are introducing plugin support for codex so you can ship your code during a the hackathon as fast as your agent builds it.

The Devfolio plugin for Codex brings all of that context into Codex itself, in a single install. No copy-pasting JSON configs, no hand-editing TOML, no juggling tabs between your editor and the hackathon dashboard.

What the plugin ships

The plugin bundles two things into one install:

• The Devfolio MCP server. Codex can read your hackathon, project, and submission context directly. .
• Codex skills for hackathon workflows. Markdown skills Codex auto-loads when a task matches, covering submission drafting, prize and track matching, tagline rewriting, and submission-readiness checks.

If you've used Devfolio MCP before, you already know what the underlying server does. The plugin is the zero-setup way to wire it into Codex, plus the opinionated skills that make Codex use it well.

Install

First, generate your Devfolio API key at Account Settings → MCP.

Then add the Devfolio marketplace to Codex:

codex plugin marketplace add devfolio/codex-plugin

Start Codex with codex, open the plugins menu with /plugins, select Devfolio, and confirm the install. The MCP server and skills are wired up automatically. You'll be prompted for your API key on first use.

Install the MCP server: codex mcp add devfolio --url "<https://mcp.devfolio.co/mcp?apiKey=YOUR_API_KEY>". See the Devfolio MCP guide for the full walkthrough.

A prompt to try first

Inside your hackathon project repo, run codex and ask:

Help me submit this project to the hackathon I'm participating in on Devfolio.

The submission skill kicks in, queries the Devfolio MCP for the hackathon's tracks and prize requirements, reads your README and source files, and drafts a submission grounded in what you actually built. You review, edit, and publish — no last-minute scramble writing a description from scratch.

Example workflows

Find the right prize fit

Analyze my project and suggest the most relevant sponsor prizes.

Codex compares your project against available tracks and prize requirements, then surfaces where your submission is strongest.

Submit a side project

Create a pomodoro timer app and push the code on GitHub, then create a side project on Devfolio

Codex can use multiple plugins and perform complex task, whether it is

Tighten the writing

Rewrite my tagline and project description to be clearer and more judge-friendly.

Codex uses your actual code as ground truth, so the description reflects what you built — not what you'd write at 3am under deadline pressure.

Devfolio Dashboard will sync with your plugin updates

Your workflow will feel more continuous. You stay in your repo, ask Codex, and get answers grounded in the hackathon you're actually in. You can always continue making changes on Devfolio directly.

Where this fits in Devfolio's AI stack

The Codex plugin is available today as a Devfolio MCP-powered workflow for Codex. It helps builders bring Devfolio context into their local coding environment.

It is also one entry point into a broader AI-native hackathon stack we are building across Devfolio.

Note: The features below are part of Devfolio's broader AI roadmap, some of them not bundled into the Codex plugin today.

• Devfolio MCP — the underlying server the plugin wraps. Works with Claude Code, Cursor, and any MCP-compatible tool.
• Whiplash — AI feedback on your project while the hackathon is still running, so you can iterate before submitting.
• AI-Assisted Application Review — for organizers, scores every applicant against a configurable rubric and flags claim-vs-proof-of-work gaps.
• Agentic Judging — clones every submission into a sandbox and produces a code-level evaluation report before human judges open a single project.

See the full AI features overview for the rest.

Try it out

The Devfolio plugin for Codex is available now. Install it, generate your API key, setup MCP, and try it on your next hackathon project.

https://github.com/devfolioco/codex-plugin

Resources

• Devfolio MCP setup guide → guide.devfolio.co/docs/guide/devfolio-mcp
• What is MCP? → nsb.dev/devfolio-mcp-explainer
• AI features on Devfolio (full overview) → Notion
• Generate your API key → devfolio.co/settings/mcp
• Plugin source → https://github.com/devfolioco/codex-plugin

Never Stop Building 🛠️

We recently ran an experiment for the Push to Prod hackathon to see if an AI system could help scale hackathon judging while preserving human judgment and taste.

Hackathon judging is usually described as a question of quality: which projects are best? In practice, it is also a question of attention. By the time submissions close, a small panel has to read descriptions, watch demos, inspect repositories, compare projects against a rubric, and decide which teams deserve glory and prizes. The work is not only subjective, A lot of it is plain inspection: what was actually built, which claims are supported by the code, and where the pitch and the artifact come apart.

That distinction became the design frame for the system. Some parts of judging are thoroughness-bound: reading code, checking claims, citing evidence, applying the same rubric across a long queue. Other parts aretaste-bound: deciding how much the evidence matters, whether the hard part was actually solved, and which project deserves to win. We built for the first part so humans could spend more of their attention on thesecond.

The result is not an AI judge in the usual sense. It is closer to an evidence layer. An agent reads the team’s submission, walks the repository with tools, writes a cited audit, and turns that audit intostructured scores a human can inspect, override, or ignore. The decision stays with the human panel. The machine’s job is to make sure that decision begins closer to the work itself.

Here are the kinds of audits the system produces:

Credited AI Depth at 9/10. The submission describes the product as a meeting summarizer. The code implements a more specific workflow: lib/agents/briefing.ts generates different artifacts for the chair, the scribe, and the operations lead; lib/schema/action-items.ts preserves owner, deadline, confidence, and source span; app/review/page.tsx makes those extracted obligations editable before publish. The implemented system turns messy discussion into accountable work rather than stopping at generic summarization.

It also catches gaps hidden deep in the codebase:

Reduced Technical Execution from 8 → 5. The submission claims “multi-tenant isolation with row-level security,” but db/policies.sql only checks that a user is authenticated, and lib/db/server.ts performs writes through a service-role client that bypasses those policies. The app may still work as a demo, but the claimed isolation is not implemented.

These examples are composites from a few real samples, but they show the shape of the assessment, the system reads the pitch against the code and leaves behind an audit a human can check. The system uses a human-written rubric to localize the judge’s attention; the decision about who deserves to win stays with the human panel.

We built a system that produces audits like this for every published project in a hackathon. An agent runs over the repository with the team’s submission text alongside it. It uses read, grep, and ls to walk the codebase claim by claim and check what the code supports. The output is a markdown report. A cheaper model turns the report into structured scores. The aggregate score is computed deterministically in code. And in the end, a human reads what matters and decides.

The first production version ran on Push to Prod submissions. It was useful enough to keep building: it surfaced implementation details and claim mismatches that would have been easy to miss in a high-volume manual review, and it produced audits that a human could inspect rather than opaque scores they had to accept or reject wholesale.

This is what we learned from treating judging as an attention-allocation problem with a constrained human compute budget.

Thoroughness and taste are different jobs

Some parts of judging are thoroughness-bound. Other parts are taste-bound.

A pipeline that routes each step to the resource with the better cost and error profile is resource allocation across humans and machines. The design follows from there.

Taste is the judgment you build after seeing many projects succeed, fail, and evolve. A strong judge is not only asking whether a submission satisfies the rubric. They are also asking: does this implementation have depth? Is the hard part actually solved? If this team kept going for another month, would the project compound or collapse? Those calls come from experience with similar artifacts. A rubric can describe some of that judgment. A model can approximate some of it. Neither carries the full set of priors a strong human judge brings to the artifact.

So yes, the machine is discerning in a narrow sense. It is good at checking evidence before it is good at judging quality. It can notice that a team claimed a custom model and shipped a wrapper. It can notice that a README describes a backend the repo does not contain. It can notice that a criterion has no cited evidence. That narrower form of discernment is valuable precisely because it leaves taste to the human layer.

What the machine can discern

The usual “LLM as a judge” setup asks the model: given this artifact, what is its quality? That framing invites a familiar set of problems. The model may reward confident prose. It may prefer its own style. It may be swayed by order, verbosity, or polish. It is being asked to compress a complex artifact into a judgment it cannot reliably ground.

We ended up asking a different question.

The agent reads the team’s pitch: name, tagline, description, tracks, demo URL, submission answers. Then it enters the repository with tools. Its job is to walk the codebase and check, claim by claim, what is and is not supported. The output is a report whose spine is claims_mismatches: places where what the team said and what the code does come apart, with file:line citations.

The hierarchy matters. The repository is the evidence. The markdown audit is the agent’s reading of that evidence. The structured JSON is an extraction from the audit. The aggregate score is deterministic compression: score × weight, computed in code, not by the model. The human decision sits on top. We trust each layer less as it gets farther from the code, so the lower layers stay inspectable.

Under this frame, a polished README becomes a longer list of claims to check. A blank README has less to disprove. Bias has not disappeared; the risk has moved. The main failure modes shift from presentation bias toward search error, incomplete exploration, and bad evidence retrieval. Those are still serious failure modes, but they are easier to inspect and easier to repair.

One kind of reward-hacking also gets harder: winning on confident prose alone. A judge that estimates quality can be coaxed toward a high score by an artifact that sounds complete. An auditor has a fixed reference to return to. If the pitch is inflated, the repository can push back. The hard cases remain hard: impressive-looking but trivial code, copied work, generated filler, hidden dependencies, or a demo path that does not match the repo. The auditor reduces the part of the scoring surface where prose alone can dominate.

The output tends toward binary questions. Is this claim supported? Is this file present? Does this implementation match the described architecture? That is a better primitive than is this a 7 or an 8? We still produce 0–10 scores per criterion because hackathon rubrics expect them, but the useful object underneath is the cited claim check. Nobody really knows what separates a 3 from a 4 in the abstract. A cited mismatch is easier to argue with.

That is why the transcript matters. When the model returns only a number, the human has nothing to react to. Accepting or rejecting the score becomes ceremony. When the model returns “docked Originality from 7→4 because src/model.ts:42 shows the ‘custom architecture’ is transformers.AutoModel.from_pretrained('bert-base-uncased')”, the human can verify or override in thirty seconds with the primary source in front of them. The audit gives the human a concrete object to appeal against: a claim, a citation, and a local reason for the score change.

This hierarchy explains the two-phase pipeline too. The expensive agent does the open-ended work: clone the repo, explore, read, reason, and write the audit. A cheaper extraction model turns that markdown into schema-shaped JSON. The extractor is not allowed to invent claim mismatches, omit criteria, duplicate criteria, change max scores, or return an overall score. Validation catches those failures, canonicalizes criterion names back to the rubric, retries parse-level errors with a retry note, and leaves the aggregate score to code.

The model does the open-ended reading; deterministic code handles schema validation, canonicalization, weighting, and aggregation.

Floor quality over peak accuracy

Is the AI actually as good as a human judge? Probably not. That comparison uses the wrong baseline.

The easy benchmark compares the model against a careful, well-rested expert with unlimited time. That person is not the system we are replacing. The real comparison is the human process under workload: a small panel, hundreds of submissions, uneven energy, uneven context.

The important question has two parts: how good can the best review be? and how many projects get a real review at all?

One way to think about this is the difference between peak quality and floor quality. A panel of humans has a high ceiling. On a project that catches the right judge at the right moment, the review can be excellent. The floor drops as the queue grows. The system becomes uneven. Some projects get deep attention. Others get triage.

The auditor has a lower ceiling than a great human judge and a more consistent floor. It does not get curious or develop taste in the way a human expert does. Its advantage is invariance under queue position: later projects receive the same exploration policy as earlier ones, subject to the same budget and harness constraints.

That trade off can be worth making even if the model is worse than an expert on any single project. The practical baseline is variance in review depth across the queue. At the prize-money end of a hackathon, that variance matters.

Agentic evaluators are a different category

Once the artifact is an audit rather than a score, the engineering problem changes. The evaluator is no longer a prompt that maps input to verdict. It is a search system over an evidence base: submission text, repository files, demo metadata, rubric criteria, tool traces, and the intermediate claims the agent writes down along the way.

That makes the harness the main object. The harness decides what evidence the agent can reach, which tools it can call, how much exploration budget it gets, what counts as a citation, how failures are retried, and which parts of the output are allowed to influence the final score. The model is one component inside that system. The evaluator is the whole loop.

Rubrics matter a lot. A vague rubric gives the agent too much freedom to substitute its own notion of quality. A good rubric is closer to a specification: criteria, weights, examples, disallowed assumptions, evidence requirements, and the boundary between claim verification and human judgment. If the rubric says “technical execution,” the agent has to know whether that means code completeness, architectural depth, deployed functionality, reliability, or some weighted combination of those. Otherwise the audit becomes fluent but under-specified.

Profiles are how the same evaluator adapts inside production. A catalog pass can prioritize coverage: inspect every project enough to surface obvious claim mismatches and route human attention. A sponsor-track profile can spend more budget on the files and flows relevant to that track’s stated criteria. A finalist profile can rerun the same project with deeper repository traversal, stricter citation requirements, and a stronger model. An appeal profile can focus only on disputed criteria and force the agent to re-check the evidence behind a specific score change. These are operating points on the same evaluation system, not environment switches.

This changes the cost model. With a single model call, the main knobs are model choice and context size. With an agentic evaluator, the knobs include tool-call budget, repository traversal policy, timeout, model choice, extraction strictness, rubric specificity, and retry strategy. You can spend more compute where the decision is high-stakes or where the first pass found uncertainty. You can also cap exploration when the audit only needs to route attention.

The failure mode changes too. A truncated prompt cannot see what was cut. An under-explored agent saw what it chose to look at, and the transcript tells you where it looked. That does not make the system automatically reliable. It makes the unreliability more diagnosable: search error, missing context, weak rubric, bad extraction, schema drift, timeout, or an unsupported inference from evidence.

The output shape also becomes part of the protocol. An agent in a sandbox can decide, mid-run, to write its report to a file instead of returning it inline. Or write half inline and half to disk. Or crash after streaming 90% of a useful report. A normal model call either returns the requested object or fails. An agent leaves traces, so the system has to recover from traces: streamed events as the source of truth, filesystem fallback, a targeted re-prompt for inline output, partial-text recovery on late-session crash.

This is the surface area you inherit the moment the model becomes a process instead of a function call. “Agentic” is mostly a marketing word, but in this system it has a concrete meaning: evaluation quality depends on the harness, the rubric, the exploration policy, and the recovery path, not only on the base model.

The same is true for observability. We ended up reading the agent’s own JSONL session logs from inside the sandbox when the vendor SDK did not surface token usage consistently. The system also persists phase latencies as it moves through fetching context, sandbox acquisition, cloning, review, extraction, and persistence. This is boring accounting. It is also how you notice that an evaluator is getting slower, more expensive, or less complete before the scores start feeling wrong. The alternative is paying for runs you cannot attribute and trusting evaluations you cannot inspect.

Disagreement is the product boundary

The disagreement between an automated judge and an expert is often treated as noise to eliminate. Some of it is. If the system misses a file, misreads a claim, or invents a mismatch, that is a bug.

The final band of disagreement is where the expert’s knowledge lives.

In the auditor frame, that is exactly where the human should spend time. The pipeline’s job is not to make the model and the human agree on everything. It is to make sure they agree on what is present, what is missing, and what has evidence. Then the human can spend attention on what it means.

That reverses the usual alignment target. If the system and the human disagree on whether a claimed feature exists, the system needs work. If they disagree on whether the implementation is prize-worthy, that may be the product working as intended. High agreement on thoroughness is good. High agreement on taste is suspicious if it means the rubric has crowded out judgment or the human has stopped looking.

A healthy pipeline converges on evidence and leaves room for human disagreement over significance.

Looking ahead

The Push to Prod experiment gave us a glimpse into what an agentic evaluator could look like. The next step is turning that experiment into a measurable, repeatable part of Devfolio’s broader judging product stack.

The audit should live where judging already happens: attached to the project, broken down by rubric criterion, visible beside the judge’s scoring/prize assignment flow, and backed by citations into the submission and repository. A judge should be able to inspect the evidence, accept or override the AI’s assessment, and continue with the normal judging flow. For organizers and sponsors, this enables configuring when audits run, which profiles apply to which tracks or prizes, and how much of the audit is shown to judges. We treat human overrides and disagreements as first-class product data.

The evaluator itself can change shape. We have run the single-judge version. A small panel of cheaper models may beat a single expensive one, especially on prize-deciding runs. Whether you want one general agent or several specialized ones is also open. We do not have enough runs to take a side yet.

Hackathon judging is the clearest version of the problem, and the same constraint appears elsewhere in Devfolio’s product surface. Devfolio sits between builders and scarce attention. Hackathons have many teams, a short window, a small judging panel, and real consequences for who gets noticed. The same pattern shows up elsewhere in our world: curators deciding which projects to feature, ecosystem teams looking for promising builders, sponsors trying to understand what actually came out of a track, internal teams comparing many artifacts without reducing them to who wrote the best pitch.

These workflows differ from judging in their risk profile. A talent-search workflow has different failure modes. A showcase page is not a prize decision. A sponsor report is not an evaluation rubric. They share one operational constraint: expert attention runs out before the artifacts do.

The useful system is one that splits thoroughness from taste, routes each operation to the resource with the right cost and error profile, and makes the boundary between machine audit and human authority explicit.

That is the sense in which the machine can be discerning. Not because it has taste. Because it can learn to tell the difference between a claim and evidence for that claim; between a working implementation and a well-written description of one; between a score that should move automatically and a judgment call that belongs with a person.

Every serious submission still needs a human decision. The point of the system is to make sure that decision begins from contact with the artifact: the repo, the demo, the cited source, the thing the team actually built. A discerning machine does not replace the judge. It helps ensure the judge is looking at the work itself.

References

• Eugene Yan - Evaluating the Effectiveness of LLM Evaluators. calibration against human–human agreement..
• Doug Turnbull - LLM Judges Aren’t the Shortcut You Think. The value of expert disagreement.
• Judging at the Synthesis hackathon.
• Vitalik Buterin - Distilled human judgment as a reference frame for scalable evaluation.
• Ben Kuhn - Impact, Agency, and Taste. Taste as predictive models and search heuristics.

In the world of high-stakes hackathons, there is a fundamental hierarchy of needs. Most people know the classic Indian adage: Roti, Kapda, aur Makaan (Food, Clothing, and Shelter). But for 800 hackers descending upon ETHIndia, that hierarchy had a critical fourth pillar: Solid, high-speed Internet.

The Evolution: Learning from the past

To understand 2024, you have to look back to our experience from previous years:

• 2022: Without authentication, the network was overwhelmed as participants connected multiple devices simultaneously. When performance dipped, hackers naturally switched to personal mobile hotspots, triggering an avalanche of RF interference that rendered the venue’s Wi-Fi unusable.
  
  We realized we had to strictly limit connections to one device per person and block bandwidth-heavy speed test websites to protect the network's capacity. Moving forward, this also highlighted the need for a dedicated “LAN Police” team to identify and penalize personal hotspot usage, while educating hackers to use USB tethering as the only acceptable mobile backup.
  
  An RCA is also published for networking at ETHIndia 2022:

w.org

GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

• 2023:  We introduced Ethernet to every table, but the daisy-chained infrastructure proved brittle. Since switches were hidden under tables, a participant accidentally kicking a cable would crash entire sections, making debugging a physical nightmare. Logically, we also battled a rogue DHCP server likely from a stray machine. However, because the network was not yet segmented, we could never perform a definitive Root Cause Analysis.

The 2024 Architecture: Redundancy upon Redundancy

This year, we started planning four months in advance. We decided on a dual-track approach: a managed service by our Networking Partner and an in-house Disaster Recovery (DR) Setup that we built, managed and controlled entirely.

1. The Main Line

We secured a 3 Gbps Internet Leased Line (ILL) with a ring topology (two separate fiber terminations for redundancy).

• Hardware: We worked with our internet vendor to procure Ruckus Wi-Fi 6 High-Density Access Points. APs manufactured post-2017 handle congestion significantly better than the older Wi-Fi 5 models.
• Zoning: We physically and logically divided the hall into four zones. If one switch failed or one zone faced an attack, the rest of the hall remained unaffected.

2. The Disaster Recovery (DR) Setup

We wanted to build our own expertise. We deployed a "beast" of a router—the MikroTik CCR2116—capable of running internet for a small city.

• Active-Active Mode: Our DR setup wasn't just sitting there; it was actively serving about 10% of the venue at all times to ensure it was "warm" and ready to take over 100% of the load if the main system failed.
• Zoning & VLANs: We used six different VLANs (Zones 1-4, Backup, and Wi-Fi) with strict firewall rules. No intra-VLAN talking was allowed, just pure, isolated internet traffic. We also ran Simple Queues with PCQ to cap each user at 20 Mbps with bursts up to 50 Mbps. Fast enough to feel snappy, controlled enough to keep the pipe healthy.
• Live Telemetry: We monitored the CCR2116 end-to-end with Prometheus and Grafana over SNMP. CPU, RAM, temperature, and per-interface traffic, all in real time. With one zone running through it permanently, we had continuous proof that the DR path worked under real load, not just in theory. The screenshot below is from peak hours: sub-4% RAM, flat CPU across all 16 cores.

Innovation in the NOC: The "Ping" Device

One of the highlights of our setup was a custom device we built: P.I.N.G (raspberry PI Network Gauge)

In previous years, debugging required carrying a MacBook (and a dongle!) to every switch, and every table. This year, we used a handheld Pi with a screen that ran real-time pings, traceroutes, DNS resolution tests, and speed tests the moment it was plugged into any Ethernet port.

It was so effective that the ISP engineers asked us to build 10 units for their own internal use (xD)! It turned the "dark art" of network debugging into a simple, handheld reality.

Swag with a Purpose

In 2023, we handed out Ethernet cables on request. But when Wi-Fi buckled under load, we had to scramble to get USB-C dongles into every participant’s hands. We had rate limiting in place via captive portals bound to MAC addresses, but participants swapped dongles constantly, so the limits were never associated to the right person.

For 2024, we skipped the scramble entirely. Every participant received a 1 Gbps USB-C to Ethernet adapter as part of their swag, branded, personal, and theirs to keep. With everyone on a dedicated dongle, we dropped the captive portal and usage limiting altogether., and a per-ip rate limit was enforced on the firewall.

On-ground Challenges

The main internet vendor’s captive portal was accidentally bound to 1.1.1.1 — Cloudflare’s public DNS. Anyone resolving through Cloudflare lost internet access, and Telegram (our primary comms channel) went dark with it.

With a large venue, hundreds of hackers moving around, and cables getting accidentally disconnected, we had to be obsessive about cable management, zip-tying runs at 2 AM to keep everything locked down.

Then there was KTPO’s metal roof. Signals bounce off it in every direction, turning the hall into an RF mess. We patched Wi-Fi gaps in specific sub-networks using TP-Link C6 Archers.

The Result: Invisible Success

In networking, if nobody is talking about you, you’ve won.

We received feedback from sponsors and hackers alike that this was the most stable internet they had ever experienced at a hackathon.

The Lessons for the future

1. Nobody cares about your architecture — until it breaks. We ran dual ISPs, six VLANs, and active-active failover. Not one hacker asked how. That’s the point. The best infrastructure is the kind nobody has to think about.
2. Give people the hardware, don’t make them ask. In 2023, we scrambled to hand out dongles mid-event. In 2024, every participant walked in with a branded Ethernet adapter in their swag bag. One change killed the captive portal, the MAC tracking mess, and the support queue in one shot.
3. Build your own debugging tools. Carrying a MacBook and a dongle to every table doesn’t scale. A 50$ Raspberry Pi with a screen replaced an entire NOC workflow — and the ISP’s engineers wanted ten of them.
4. Segment everything. Trust nothing. A rogue DHCP server in 2023 took us down and we couldn’t even trace it. Strict VLANs and firewall rules in 2024 meant one zone could burn without taking the hall with it.
5. RF is the real boss fight. Metal roofs, 800 personal hotspots, Wi-Fi 5 APs from 2015 — no amount of bandwidth fixes physics. Ban hotspots, enforce wired-first, and zip-tie your cable runs at 2 AM like the rest of us.

Until next time, never stop surfing 🏄‍♂️

1500+ builders. 680+ projects. $100k+ in prizes. A live experiment in whether machines can evaluate what humans build.

The rules for how AI agents operate in the world are being written right now. Not in whitepapers. In the actual decisions being made about what gets funded, what gets built, and what infrastructure gets adopted while everyone else is catching up.

The Synthesis was a live trial of whether machines can evaluate what humans (+machines) build.”

A different kind of hackathon

Most hackathons run on a platform. Synthesis was a platform.

We didn't use the standard Devfolio submission flow. We built an entirely new system from scratch — one where the participant wasn't a human filling out a form, but an AI agent reading a skill file and registering itself.

To participate, builders had to use an agent. OpenClaw, Claude Code, Cursor, Codex — any coding agent that could read synthesis.md/skill.md and act on it. Your agent read the instructions, registered on your behalf, and submitted your project. If you didn't have an agent yet, the team helped you spin one up.

That was the point. The builders weren't just building for agents. The builders were the agents

The numbers

685 projects submitted across 10 days.

1,500+ builders registered.

28 partners — each contributing a bounty, a judge agent, and real technical resources.

$100,000+ in bounties across open and partner tracks.

11 partners voluntarily pooled $28K+ into a shared Open Track — no single company controlled it, no one was asked to contribute.

Judging: thoroughness + taste

Hackathons have an evaluation problem. A handful of humans, hundreds of projects, a compressed window. The first submission gets fresh eyes. The fiftieth gets a tired judge at 11pm.

The Synthesis used a compositional judging system.

Every partner onboarded their own AI agent judge, powered by Bonfires.ai. Each agent was trained on that partner's specific criteria — their rubric, their technical priorities, their theory of what "good" means. MetaMask's agent cared about delegation patterns. Lido's cared about yield mechanics. SuperRare's cared about whether the code was the art.

Not one agent, but 28 agents, each encoding a different perspective.

The agents brought thoroughness — code reviews, deployment checks, cross-referencing README claims against what was actually deployed, 15–20 minutes per shortlisted project. Things that simply don't happen at a traditional hackathon.

But the agents lacked taste. That's what the human partners brought. The system was designed so neither could produce the final outcome alone. The agent proposed. The human decided.

The workshops

While builders were building, partners were teaching.

We ran [X] livestreams and workshops over the 10 days — from opening ceremony deep-dives to hands-on sessions on agent wallets, onchain skills, and design ideation. Partners from across the Ethereum ecosystem showed up to put their tools directly in front of builders who were actually using them.

All sessions are archived → Watch the full playlist

Winners

Check out the announcement of Synthesis Track winners here: x.com/synthesis_md

You can browse the full set of submissions here: synthesis.devfolio.co/projects

What we learned

Agent judging works when the rubric is visible. The moment builders can see what a judge is optimising for, the whole thing feels fair.

Virtual + async + 10 days is a real format. 685 submissions proves builders don't need a venue when the problem is interesting enough.

Partners who build their own judges stay engaged differently. Creating a judge is an act of authorship. It anchors a partner in a way a logo never does.

The pattern extends well beyond hackathons. Anywhere high-quality human judgement is the bottleneck — grants, governance, peer review, due diligence — compositional evaluation offers a path forward. Machines scale the reach. Humans anchor the values.

685 projects is a stress test. The implications go further.

To every builder who shipped

Every project got read. Every README was evaluated. Shortlisted projects got a full code audit. The agents didn't skip anyone because it was late and they were tired.

That's the minimum standard builders deserve. It took rethinking the entire evaluation stack to deliver it.

And for the peace of mind and fairness, projects were again judged by human judges.

Quick Links

• 🌐 synthesis.md
• 📦 All projects
• 🎥 Workshop playlist
• 🐦 @synthesis_md
• 💬 Community chat

Stay tuned for more experimental hackathons with the Devfolio community at:

🐦 Twitter · 🦄 Farcaster · 🎮 Discord · 📞 Telegram

🛠️ Never Stop Building

Once in a while, we host hackathons with a concise group of builders in a different country. This time, it was Singapore. As of writing this, Singapore also happens to rank #1 in AI adoption according to the Anthropic Economic Index.

On 24th April 2026, we hosted Push to Prod Hackathon by Genspark and Claude, in partnership with Genspark.ai, Anthropic, and Temasek, at Temasek Shophouse. We had over 100 builders joined us in person to hack at the venue.

At a glance, 100 hackers might not sound like much. But hackathons are never about scale for the sake of it. Push to Prod was designed as a 5-hour sprint for working professionals to come together and build something that had been slowing them down in their workflow for a long time.

From Idea to Output in 5 Hours

What stood out immediately was the pace.

Building functional projects in 5 hours used to feel unrealistic. That is changing fast. With AI agents and coding platforms evolving rapidly, the bottleneck is no longer writing code line by line. It is thinking clearly about architecture, workflows, and how your system should interact with intelligence and how you as a builder can make use of resources and orchestrate them properly to build a working project.

With access to Genspark and Claude, builders got straight to work.

By the end of the sprint, we had:

• 107 builders checked in
• 45 projects were submitted
• Every single project was built during the hackathon

The output was not just fast but was practical as well. We had teams that worked on internal business tools, reduced repetitive design loops, and built systems that could immediately plug into their day to day workflows.

Setting the Stage

To kick things off, we had two sessions that helped builders get up to speed quickly for building in the next 5 hours of the hackathon

Jennifer Lin, Head of Marketing from Genspark walked through how teams could effectively use Genspark and Genspark Claw in their projects, while Katelyn Lesse, Head of Platform Engineering at Anthropic, introduced how to work with Claude in a practical, builder-first way with insights into the architecture of how Claude is built and thus how builders can make the most of using Claude for building their projects

Both sessions were short, sharp, and immediately useful. Although the tools are widely known, builders got a good amount of understand of the architecture of agents of both the platforms and how to make the most of them to build their projects.

The Most Focused Hackathon Room

Right now, the internet loves to portray builder culture as loud and chaotic. Fast cuts. Dramatic music. Energy spilling everywhere.

But when people are actually building, especially in a high-focus offline environment, it looks very different and I am happy to be reminded of how a focused mindset and work looks like via this hackathon.

This was one of the quietest and focused hackathon rooms I have seen in a long time. You could hear the keyboards and the Occasional clicks, with literally a pin drop silence and builders glued to their screen for building their projects in the 5 hour sprint

More than 100 people in a room, fully locked in.

We usually spend a lot of time walking around, talking to participants, collecting feedback, and being in the middle of everything. This time, it felt out of place to interrupt. Everyone was deep in their flow. Conversations only really picked up during lunch and snack breaks.

And this was so much interesting to watch unfold IRL during the hackathon.

Builders, Conversations, and Context

We saw something similar during BlockTrain. When you keep the group concise, the nature of interaction changes and is so much more interesting and the focus you can bring to the conversation to make it fruitful

At Push to Prod, we had the ratio of

• ~70% working professionals
• ~30% students

which worked towards solving the daily bottleneck problems in their workflow. Conversations with such a focused group of builders were more grounded and contextual. Less about experimenting for the sake of it, and more about solving real problems.

The overall sentiment was practical and optimistic in the room.

Devfolio MCP in Action

This was also one of the first hackathons where we rolled out Devfolio MCP for submissions.

Instead of filling long forms, builders could submit projects by chatting with an agent directly from their terminal.

It made submissions significantly faster and kept the focus where it should be on building. Devfolio MCP is now live in production and available to all hackers once they check in to a hackathon.

The Top Projects

Out of 44 submissions, after almost an hour of shortlisting, we were ablet to get to the top 5 teams for the hackathon who then presented their solutions on the stage.

Top 5 (in no specific order):

• Vendor Wrangler
• Atelier
• Unscatter
• Project Godiva
• ConnectCrew

The evaluation was conducted by Jo Kennedy from Anthropic, Jennifer Lin from Genspark, and Maynard Kang from Temasek.

Participants competed for $18,200 worth of credits from Genspark and Claude.

Final Winners:

🥇 ConnectCrew
An AI-powered CRM that uses a crew of specialized agents to automatically keep your professional relationship graph up to date.

🥈 Vendor Wrangler
An AI agent that handles all your vendor communications and negotiations so you never have to email a supplier yourself.

🥉 Unscatter
An AI-powered knowledge base that automatically organizes your company's scattered information into a searchable, always-up-to-date brain.

Pushing to Prod in 5 hours

It was genuinely fun putting this together.

The venue added a lot to the overall experience. A special shoutout to the Temasek team for hosting us at Temasek Shophouse and making the entire event seamless.

Push to Prod was one of the most concise hackathons we have hosted in the recent times and it was so much refreshing to see the builder's focused energy towards their projects in the event.

For more updates on our initiatives at Devfolio, checkout our socials at:

    🐦 Twitter                          🎮 Discord                  📞 Telegram

In case you missed the hype on the internet this month. Here's a quick tl;dr

ClawdBot (now OpenClaw) was made by Peter Steinberger  in 2025, which grew in popularity thanks to advancing AI models like Opus 4.5 and GPT 5.2 working very well with agents.

OpenClaw is an open agent platform that runs on your machine and works from the chat apps you are familiar with. WhatsApp, Telegram, Discord, Slack, Teams and more.

It's diverse support allows it to be hyper-configurable and MCPs allow openclaw to work with almost any tool that has MCP support.

Speaking of MCP let's talk about ours 👇

Step 1: Set up Devfolio MCP

MCP is a beta feaature so you need to enable Beta program in your account settings. Don't worry you can always turn this off.

Devfolio -> Account Setting -> Join Devfolio Beta

You'll join beta immediately and will see a new MCP tab on the sidebar

Step 2: Set up OpenClaw

You can always go to the official documentation for more details.
For now here's one (of many) ways to install OpenClaw

If you already have node npm install -g openclaw@latest

After installation

• Run onboarding: openclaw onboard --install-daemon
• Quick check: openclaw doctor
• Check gateway health: openclaw status + openclaw health
• Open the dashboard: openclaw dashboard

Most of time, openclaw will take you through these steps as part of the onboarding and you will land directly on the dashboard after finishing installation.

You can, at any point, go back and re-configure your installation so do not worry if you missed setting up a plug-in or wish to change the AI model using openclaw.

[terminal image here]

PS: To uninstall openclaw: openclaw uninstall

While we are at it, we'll also set up GitHub auth for our bot (I created a separate GitHub account for bot)

gh auth login

This allows cli tools to create repos, push/pull repos directly from terminal. In this case, by our bot.

We recommend connecting GitHub auth manually by terminal and letting openclaw know once its done than sharing credentials with openclaw and letting it do it. It's always safer to give minimal credentials (or onces that aren't connected to personal accounts) in any way.

Step 3: Give OpenClaw a way to talk to you

We recommend telegram but you can also pick Whatsapp or any other supported channel.

For telegram, You'll create a new bot and need to get a telegram bot token. from @botfather. Feed that to openclaw during setup.

Next up, setting up our Devfolio MCP on openclaw. In my case, I simply pasted my MCP key to openclaw and it figured out how to apply it.

You can use the terminal or the GUI to interact with openclaw for this

With Telegram and Devfolio MCP we can now chat via telegram from any device to our openclaw bot.

We can now chat with openclaw to show what it can do with the Devfolio MCP

• Creating and updating project on Hackathons hosted on Devfolio
• Managing side projects on your profile

As long as you are participating in the hackathon, openclaw can take care of the rest.

With all things set, Let's make a submission to this hackathon.

I created this test hackathon to make a clean submission and observe how less I have to touch code.

Giving the initial idea and implementation took some time. OpenClaw also threw errors but most of the time bounced back before failing (often due to permission error or missing package)

Once the bot got into the flow with appropriate permissions across the board, it did not wait long to push the simplest pomodoro app.

Later I also wanted to add a Demo Video with remotion, so I let it explain how to set that up too, and then carry it forward with the creation.

I did not even had to open the directories to check the code or the video. I let my bot share me links to review all in once place.

And that was it! It took me more time to set the bot (one time setup) than to have it make the project, demo video & submit to the hackathon.

Most of the time I was writing this blog while it coded out the rest :D

This opens door for more agent-driven hackathon formats where you can focus on the exciting part and let the agent do the daunting task for you. However it comes at costs and I'll list those here:

• It's no fun if agents do everything. In hackathon, the thrill (and core learning) comes when you push yourself to be uncomfortable enough to learn that new tech you wouldn't otherwise. Regardless if it seems boring, complex or unknown
• Your story matters, content does not. Any content based task is easy to populate with GPT but it takes away the essence of storytelling you could've made during Demo or project explanation. Often it's these storytelling that gives you the edge to win during judging (Personal experience!)
• Are you even learning? kind-of. If the AI can do everything for me, I am only learning to instruct the agent, not to make the app myself. Agent-Driven-Development is turning out to be a hot skill but it's only a credits-run-out away from leaving you helpless. Emphasize not to over-rely on the agent you build. It should be meant to help you take care of repetitive tasks, not the ones that can teach you (even repetitive tasks can prime us in problem solving!)

That's all for now, we'll come back with more complex and exciting ways of using AI agents in hackathons.

Never Stop Building  🛠️

Last month, Mumbai hosted its Ethereum hackathon: ETHMumbai 2026.
Here’s a quick tour, no bus required :P

Built in motion

Over the years, we have been hosting ETHIndia, bringing builders from across the country together. Now, we’re seeing more teams, more cities, and more communities step up and carry this forward.

We were super excited to see ETHMumbai kick off in 2024 and push things even further this year. What once felt centralised is now expanding into a decentralised set of nodes, with new hubs taking shape and building their own momentum.

With Devcon set to arrive in India, this year already feels like an inflection point. In many ways, it’s a moment that’s been a long time coming,

Chapter 0: Mumbai in Progress (MIPs)

Every great event has a pre-story. ETHMumbai’s was the MIPs.

Mumbai In Progress meetups happened before the main event: small, community-led sessions where builders across the city came together to talk, build, and figure out what ETHMumbai could be.

Chapter १: The Start

The conference kicked off with a Dhol Tasha performance, a traditional drum ensemble that got the energy going from the first beat.

From there, the day unfolded across multiple formats: Double Deck for keynotes and core talks, Single Deck for workshops, and Open Deck, where parallel sessions ran through headphones.

A key moment was the Devcon announcement, where the team introduced the Road to Devcon and broader ecosystem programs, connecting India to the global Ethereum community.

The ETHMumbai App tied everything together, making it easy to navigate sessions and stay in sync throughout the day.

Chapter २: The Build

The next day, we moved to the World Trade Centre for the hackathon.

With 200+ hackers on the floor, the energy was instant, teams forming, ideas moving fast, and the buildathon kicking off.

Mentors and organisers kept the energy tight, workshops ran in parallel, giving builders the depth they needed to sharpen their approach. Over the next 36 hours, teams built across tracks from sponsors including Base, ENS, HeyElsa, Fileverse & BitGo.

Interval

The team also organised a guided bus tour across the city as a short break during the hackathon.

Scheduled in the evening, it wound through South Mumbai, past CST, the Gateway of India, and the Taj. For a couple of hours, the laptops stayed shut, and the city took over.

Cameo: Kaali-Peeli, Camera & Action

In between all of this, we managed to pull off something we're pretty proud of. In collaboration with Devcon and ETHIndia, we sat down with some prominent web3 figures for a series of interviews, filmed inside Mumbai's iconic kaali-peeli taxi.

The conversations captured builders’ stories, their journeys, and how they found their way into the Ethereum ecosystem.

It was a fun format, and honestly, a fitting one for the city.

Chapter ३:The Final Stretch

As the hackathon entered its final stretch, the focus shifted to refining ideas, debugging relentlessly, and pushing projects toward submission.

The result ...

With over 80 projects built and a prize pool exceeding $10K, the stakes were clear, and the energy stayed high until the very end.

The hackathon brought together a strong lineup of judges and mentors to evaluate and engage with the work on display, including Denver Dsouza from Devfolio, who was there helping guide and evaluate the projects being presented.

Here are the builds that turned heads:

1. penumbra
2. ppn.fi
3. MeshSearch

Beyond the hackathon …

All around, ETHMumbai was an experience of its own, from how the events were designed to the builder mindset, everything carried a distinct pinch of Mumbai.

And when hackers left the venue, they didn’t just leave with experience; they carried a small piece of the city with them.

With Devcon set to be hosted in Mumbai later this year, we’re excited to see the city bring that energy back on an even bigger stage.

A big thank you to all the volunteers, hackers, and partners who made this experience what it was. We can’t wait to share what we have in store for November.

Till then, Never Stop Building 🛠️

Stay tuned for more updates and interact with the Devfolio community at:

🐦 Twitter                 🦄 Farcaster                   🎮 Discord                  📞 Telegram

We had a chance to host Build India Hackathon in partnership with Anthropic, Replit and Lightspeed in Bengaluru on 15th February 2026.

For a long time, building meant writing logic, connecting APIs, designing interfaces, and hoping users would adapt to the product. Now, intelligence is part of the foundation. Small teams can build things that once required serious scale That shift is still unfolding, and no one has fully figured it out yet. And that’s what makes the present interesting.

Build India was a focused sprint with dedicated hours to think clearly, build seriously, and ship something real using Claude and Replit. It was about building something beyond a mockup, something that functionally works.

What followed was an 7 hour hackathon of teams working with AI to build something for India and from India.

Setting the Stage

Starting from builders showing up at 8:00 AM for registration, the day kicked off with a fireside chat featuring Irina Ghose (Managing Director, Anthropic India), Jeff Burke (Replit), and Hemant Mohapatra (Partner, Lightspeed India).

Their keynote went beyond generic AI hype: they discussed how Anthropic and Replit are collapsing the gap between ideas and production software, what it really takes to move from chatbots to reliable agents, the metrics that predict whether an AI product will stick, and why India’s developer ecosystem is now central to that future.

They also shared their views on where AI is still too brittle to be trusted without human oversight, and what would make a weekend hack at Build India feel like the seed of a real company rather than just a clever demo and just after few session from Anthropic and Replit the hackathon started.

The Build Hours

As the opening wrapped and the timer began, ideas went up on a shared tracking board. Teams posted what they were building and updated their progress in real time.

Then laptops flipped open, Idea board filled up, and the entire venue settled into deep focus. Builders locked in fast. From solo devs with laser-sharp prototypes to full teams debugging across three terminals, the room was alive with intent.

People of Build India

Team members from Anthropic and Replit were present throughout the day, helping teams troubleshoot, refine prompts, and push their builds further. Credits from both platforms were provided so participants could fully experiment without constraint.

The feedback was direct and practical, often sparking the kind of small insight that completely changes a product’s direction.

Prize Breakdown

The prize pool was divided between cash awards and platform credits.

🥇 First Prize
- Cash Prize: $2,500
- Credits from Anthropic: $7,000 worth
- Credits from Replit: $7,000 worth

🥈 Second Prize
- Cash Prize: $1,500
- Credits from Anthropic: $5,000 worth
- Credits from Replit: $5,000 worth

🥉 Third Prize
- Cash Prize: $1,000
- Credits from Anthropic: $3,000 worth
- Credits from Replit: $3,000 worth

Winning Projects

🥇 Grand Prize ($16,500) - Chat2cash by @swayyaam
Millions of small businesses rely on WhatsApp for sales, but most still manage orders manually. Chat2Cash helps them turn chats into invoices, tracked payments, and recovered revenue.

🥈 First Runner-Up ($11,500) - Claude clip by @adithya_s_k and @spratyey
ClaudeClip is a video editor where AI and humans co-edit together: you describe the video you want, Claude assembles a first cut from your footage with text, clips, and graphics, and you fine‑tune it on a familiar timeline.

🥉 Second Runner-Up ($7,000) - AI Battle Royale by @ArshanKaudinya
AI Battle Royale is a competitive arena where LLM agents fight to survive, exposing their real-time strategic reasoning under pressure. It transforms response speed, spatial tactics, and survival decisions into a live, interpretable benchmark for multi-agent AI behavior.

Check out the rest of the projects here → buildindia2026.devfolio.co/projects

👀 What’s Next

📸 Photos!
The full event gallery can be found here: Build India 2026
And the BTS will be dropping soon on Devfolio’s X.

Relive the energy, spot your team, and share your favorite moments!

Keep Building

Build India 2026 ran on energy you could feel in the room. The focus, the last minute pivots, the random sparks of clarity. It all added up to something special.

Maybe you shipped something you are proud of. Maybe you hit a wall and learned more than you expected. Either way, that momentum is real. The ideas you started here do not have to end here.

Keep iterating. Keep testing. Keep talking to the people you met this weekend. The best part of any hackathon is not just what gets submitted. It is what keeps growing after everyone goes home.

When the next Build India opens, you will hear from us first. Until then, we will keep sharing updates, builder spotlights, and new opportunities to jump into. If you are already thinking about your next challenge, explore what is live on Devfolio at devfolio.co/discover.

If you built something during the hackathon, post it on X and tag us. We would love to see what you shipped.

Until next time,
Never Stop Building

P.S. - We’d like to give a special shoutout to all the contributors for helping make Build India 2026 a smooth and seamless experience.

Nobody would have believed us if we'd just told them. So we showed them instead.

For months, we'd been wrestling with a question that kept us up at night: What if we could create an environment where builders didn't have to hunt down mentors in forest-sized venues, where meaningful conversations didn't get lost between networking sessions, where the experience itself became the ROI?

The answer, as it turns out, was a 36-hour train ride from Bengaluru to New Delhi. Well one of the answer was this. 😛

Welcome to BlockTrain. On-chain, on-train. 🚂

Trying out something NEW!

The traditional hackathon format works. Invite builders to a venue, provide resources, announce prizes, everyone goes home. Rinse, repeat.

But here's what we noticed: builders rarely get enough time exploring and making the most out of hackathons while working on their projects. Mentors become scattered resources you need to track down. And that fundamental question -"What did I actually get out of this?" - often doesn't have a satisfying answer beyond a prize or a project submission. While on the other side, organizers think, plan and curate for a wholesome experience for everyone which only a fraction of people are able to enjoy or take part in.

We realized that despite all the effort that goes into organizing large-scale events with workspace, mentors, food, and talent, measuring the real fruitfulness of such gatherings is surprisingly difficult. The infrastructure is there, but the depth of connection? That's harder to guarantee.

So we asked ourselves: What if the venue itself forced valuable conversations? What if builders and mentors were locked in together - literally and metaphorically - with nowhere to go but deeper into their conversations and their code?

Inspired by Jagriti Yatra and The Hack Zypher, we had an idea: a blockchain hackathon on a moving train - Blocktrain!

Once we hit publish on the announcement, we honestly weren't sure what to expect. A hackathon on a moving train? It sounded either genius or completely unhinged - possibly both.

The announcemenet on twitter blew up with builders from everywhere asking how they could get on board. Creators like Caleb shared the initiative, and his reel on instagram crossed 900K impressions. For something that started as a wild idea scribbled during a late-night call, seeing it resonate like this felt surreal.

The People: Who We Had On Board

5,000+ applications. 120 shortlisted. 45 brave builders to rewrite the history of building on train!

This was our first experiment, and we had exactly one bogie on train to work with. The selection was intentional - we wanted builders who understood that this wasn't just about shipping a project. It was about being part of something unrepeatable.

Really glad we had sponsors including Base, Noice and Geode with whose help we were able to manage all the logistics for BlockTrain.

Alongside the builders, we had:

A handpicked crew of mentors who weren't just experienced—they'd walked the path. Folks who'd built proof of work at places like Noice.so, polynomial.fi, rath.finance, and BuidlGuidl. They weren't there to lecture. They were there to rotate through berths, sit down with teams, and actually jam on ideas.

Four creators roaming free across compartments, tasked with capturing this entire experiment through their lenses. Not assigned to any specific group, just there to document the beautiful chaos as it unfolded. The content they put out on Twitter? People absolutely loved it.

A train full of people who cared about building.

The Logistics (Or: How We Pulled Off Something Technically Hard)

With crazy ideas come crazy challenges. Sorry, Spiderman. 🦸 😬

Internet at 120 km/h

This was the big one. You can't exactly rely on mobile hotspots when you're barreling through railway tracks in India. So we set up an intranet system on BlockTrain with a simple concept: store all the npm packages locally and let builders chat with an onboard LLM to pull what they need for building up their projects.

Food that you love :D

It's crazy to go back and see how we co-ordinated across our vendors from stations to have food available to all the builders on train. While we did have IRCTC catering, we were recommend to order the famous idli, vada and sambhar from a beloved local spot from Hyderabad, with snacks and dinner from Bikanerwala at Nagpur junction. Three different sources, three different vibes, all of which people loved the food from all three locations

Permissions (The Bureaucratic Boss Battle)

As anyone would have guessed - hosting a hackathon on train would require good amount of permissions from the government bodies.

Getting bulk ticket bookings for builders? Manageable. Booking extra emergency tickets in case teams needed space to code in peace? Doable. Getting official permissions from railway authorities to run a full-blown hackathon on a moving train? That required trips from New Delhi to Bengaluru railways and back again. But we pulled through. Special thanks to our fren @Amogh - who helped us out in the planning and ops for the whole BlockTrain initiative. Couldn’t thank him enough. 🤝

A thoughtfully curated swag list

We realize swag is an important inclusion in any of the events we host.  For blocktrain - a ride worth 33 hours, We thought about what builders would genuinely need on a 36-hour train ride and thus had the following in the pipeline:

• T-shirts (obviously)
• Eye masks (for those who actually wanted to sleep)
• Dental kits (hygiene is not negotiable)
• Sponsor branded N95 Mask
• A portable table specifically designed for coding on the train!
• Sticker sheets (because builders love stickers)
• An exclusive BlockTrain-branded keychain
• And a memento for everyone who built on the train
• Tote bags (to fit all of the above)

Initially we didn’t think we would have this many items but eventually the items made their way into the bag and I love the fact that people LOVED this and shared their love over social media about the swag bag!

The Opening: Setting the Stage

Before anyone boarded, we held an opening ceremony at PVR Yeshwanthpur - Vaishnavi Sapphire. Cinema hall. Big screen. The ADGM Deputy Railways Bengaluru joined us.

We briefed all 45 builders on what to expect: the format, the challenges, the vibe. Then we assembled everyone, lined them up, and marched them to the railway station together.

One line. One train. One shared experience about to begin.

Day 1: Departure and Immediate Chaos (The Good Kind)

What we planned: Keep the first night light. Let people settle in. No pressure to code immediately.

What actually happened: The train hadn't even left the platform before laptops started opening.

We thought builders would want to rest, ease into things, maybe chat and get comfortable. Instead, the moment the train departed Bengaluru, screens lit up across compartments where the IDEs launched terminals started and the builders fired up to code on train. Honestly, the energy was electric.

You just had to be there to see it. Builders weren't waiting for permission or a formal kickoff - they were already locked in.

The theme to build on train was open: build anything on-chain. No restrictions. No prescribed problem statements. It was just pure builder autonomy.

Day 2: A whole day on the Train!

If Day 1 was about finding rhythm, Day 2 was about controlled chaos turning into a really magical experience.

Morning: The Grind

Mentors began their rotations after the morning idli sambhar from Hyderabad, moving from berth to berth to discuss ideas, validate assumptions, and pressure-test early prototypes. It was quite fun to see everyone engaged in discussing their ideas and projects they were gonna build.

Teams dug deeper into their builds. We had two special tracks running in parallel:

Ethereum Speedrun Challenge sponsored by BuidlGuidl which required builders to Complete a Prediction Markets challenge for a shot at $300 prize pool.

The other prize was for the first three teams mentored by JesseGPT who posted on social media won $20 each.

Quadratic Voting with Anon Aadhar: A $1,500 prize pool where the community decided who deserved recognition. Every team that submitted a functional project on-train earned $20 per team member. You can check the leaderboard at https://blocktrain.devfolio.co/quadratic-voting.

Night: This was Crazyyy!

Here's where things got beautifully absurd.

Picture this: One compartment has builders hunched over keyboards, translating their thoughts into code or maybe debugging, well it goes in parallel at 11 PM. The next compartment? A full DJ setup with music projected onto the train's windows, people vibing to beats as the countryside blurs past. The compartment after that? A intense game of mafia where teams are trying to identify the murderer while murdering their own sleep schedules.

All of this. Simultaneously. In the same bogie.

Apart from this, we had our engineers engage Some folks broke into spontaneous on-train antakshri. Coffee was served at odd hours. Old-age cartoons played on someone's screen. The entire bogie had become a living, breathing organism of focused work and joyful chaos.

This was the night people would remember.

Day 3: Arrival and the Proof

8:00 AM sharp. New Delhi.

The train pulled into the station right on time. Everyone gathered for photos but before that we handed out mementos to every builder who'd completed the journey. Not for winning. Not for ranking. For doing it. For building something functional while traveling at 120 km/h. For being part of the world's first Ethereum train hackathon.

We had 21 submitted projects. Read that again. In 36 hours, on a moving train, with limited internet, builders shipped real functional work.

We waved goodbye to the creators and builders as they dispersed into Delhi, carrying momentum into the week ahead. BlockTrain being the prologue - the caravan that set everything in motion.

On-Chain, On-Train, On to the Next

BlockTrain happened. It was real, chaotic, and it was everything we hoped it would be.

To the 45 builders who took the leap: you're now part of something that didn't exist before. To the creators who captured it: your work made sure no one will forget. To the mentors who gave their time and wisdom in transit: you made this more than just a gimmick.

This was the ceremonial start to a week where Ethereum in India took center stage. But more than that, it was proof that the best gatherings aren't always the biggest ones - sometimes they're the ones where you can't escape each other, and you wouldn't want to anyway.

The train has reached its destination. But the journey? That's just getting started.

Quick links here:

We tried to capture everything in this post, but some things just spill over. If you want to go deeper:

• Submitted projects - 45 teams, 33 hours, one moving train
• Photo album - All the moments from the train journey

And here's the thing - so many people posted about BlockTrain that we couldn't possibly include it all above. Builders sharing their experience, strangers hyping us up, honest takes from everyone who was there (and many who wished they were).

We've gathered some of our favorites here:

• https://x.com/devfolio/status/1964994554651943133
• https://x.com/denverjude/status/1969403674561822949
• https://x.com/aazim_anish/status/1969599351602495935
• https://x.com/Ayussheth/status/1969709347295912157
• https://x.com/devfolio/status/1969712742052565451
• https://x.com/DholakiaJaydeep/status/1969752065695166644
• https://x.com/heettike/status/1969811115694563667
• https://x.com/aazim_anish/status/1971156499566297449

For more updates on our initiatives at Devfolio, checkout our socials at:

🐦 Twitter                 🦄 Farcaster                   🎮 Discord                  📞 Telegram

Our mission for 2025 was clear: We are doing things differently this time.

ETHIndia came back with a new version this year, ETHIndiaVilla.  

A tighter circle of Ethereum builders, a more intentional format, and an experience designed for real collaboration.

This edition brought together a team of selected builders for a format built around depth. Teams will work in groups of three or four, and every team will be joined by a Super Hacker. We received 2,045 applications this year, out of which we shortlisted 52 of the best hackers in India to work with Super Hackers in this edition.

Super Hacker - The wild card of every team.

Why shift the format? We want to create a space where builders can think sharply and learn faster. Every team is paired with a Super Hacker who brings real-world insights from the products they work on every day.

Super Hackers are the past mentors and judges you have seen guiding ETHIndia in previous editions, but this time, they were building inside the same team. The concept of Super Hackers was chosen from our community feedback and our intrinsic motivation to shift focus on the quality of mentorship and project outcomes of ETHIndia.

Super Hackers were professionals at their work from Base, Crossmint, Caddy Finance, Polygon Labs, Arbitrum, KelpDAO, Lucidly Finance, StarkWare & Privy

The role of a Super Hacker is a middle ground between mentor and hacker; they are advisors but also part of the team:

• Super Hackers have extensive experience in Ethereum, professionally & as past ETHIndia attendees. This increases the bar for each team with improved mentorship and creativity.
• Super Hackers being part of the team also means they are motivated to double down their efforts in making their team win. This is difficult to achieve in traditional mentorship, where you are assigned to all or a set of teams.

The result...

17 Solid Projects from 17 Teams, each paired with their own Super Hacker

The purpose of Super Hacker was not just technical expertise; it was also the industry experience and bringing together veterans with future builders.

Here's what Super Hackers felt about the new format of mentorship

Big Boss wants you to play

We have run the standard hackathon format many times over the years, so this year we wanted to bring something fresh for everyone. And it was not just hacking. The villa had activities planned that made the overall experience richer, more engaging, and a lot more fun.

We inserted three games to add a vibeathon spirit for the IRL hacking phase.

1. Fastest Pani Puri First: Test your Ethereum ecosystem and technical knowledge, but instead of a buzzer, you have to make and have a pani puri.
2. SpaghETHi Marshmellow: Midnight break from hacking (and potential snacking) by creating a structure using only Spaghetti and Marshmallows.
3. Proof of Pool: Post submissions, hackers compete for swag by scoring the most by tossing into the floating hoops.

Prizes for these games were equally rewarding. We had Hardware Ledges & exclusive ETHIndia Swag on the line just to play these games and give everyone a great time.

Reward more than just bounties

We wanted our hackers to be rewarded with something you cannot put a price on, a Connection with industry's best. Spending 24 hours with Super Hackers at the Villa allowed these hackers to bond at a greater level than mentors at a traditional hackathon.

This resulted in a deeper connection that butterfly effects into networks as the builder continues their journey in the Ethereum ecosystem. "We met for the first time at ETHIndia" is a traditional experience witnessed by many developers in India.

Quadratic Voting so everyone wins

We continued doubling down on the benefit of Quadratic Voting to fairly reward the best projects. On top of QV, Anon Aadhar makes it possible for every eligible Indian (with a valid AADHAR card) to participate in QV without identity disclosure.

This means hackers are incentivized to advocate for their projects.

More advocacy = More votes = More share of the prize pool.

Turns out, doing things differently works

We are proud and honored that we got to try new formats this year. From running BlockTrain, the World's first Ethereum hackathon on a moving Train to ETHIndiaVilla. The recognition and love from hackers, sponsors, and communities tell us that our efforts are in the right direction and towards what builders and problem solvers also want.

Cheers to a lot more building, good times, and experiments in 2026.

Quick Links of ETHIndiaVilla:

• ETHIndiaVilla Projects
• Photo Album
• Villa Stories

Stay tuned for more updates and interact with the Devfolio community at:

🐦 Twitter                 🦄 Farcaster                   🎮 Discord                  📞 Telegram

Never Stop Building & a Happy New Year :D

Hi, I'm Ashwin. I am the head of community at Devfolio and I just completed a year here! Let me take you through what I did over the last year.

Hackathons aren't new to me, I used to ~hate~ code (ever coded on MS-DOS? You'll probably relate).

Hackathons Are for Learners, Not Just Students

Contrary to the popular assumption that hackathons are for "hackers", hackathons makes the most sense for (relative) beginners. If you want to learn a new technology, tool or even understand the hype everyone's talking on Twitter, picking a hackathon is the best way to understand it without sacrificing money, time or work/school.

Build Teams Beyond Your Circle

Frankly, for me, some of the best career friends came out of hackathons. The ones where I chose to form a team instead of bringing one. This eventually led to a butterfly effect that got me into international conferences, great career options and cool friendships in new towns when moving.

Team formation is a core area many hackers ignore as they like to bring their friends who they are comfortable in communicating with. Unfortunately, in professional spaces, you may not know everyone and learning how to communicate is a core software engineering skill (Way more important than any JS framework).

Putting yourself in the uncomfortable space of team formation does a few things

• Encourages you to sell yourself (with your experience & motivation) to others.
• Holds you accountable for your duties in a team for the sake of reputation.

When you are hacking with a bunch of good-ol' friends, it's very easy to bail out, take up tasks or even build the project cause you may end up spending more time hanging-out than hacking, which can be distraction.

In a new team, you are bound to show progress for the sake of maintaining that new connection with the team mate who may know more than you one certain skill-level. Conversly, same happens to them as they find a skill you are better at.

Shared struggles solve better problems

I know you want to solve that one problem in the ecosystem, but when you pick a problem everyone relates to, you motivate everyone to join you.

The concept of shared struggles applies to all forms of bonding. Apply it to team formation and you get a super-solid team that  believes in the same cause. Apply it to your project and you'll impress the judges who had a relatable problem.

Ideation is the least invested area of a hackathon. Most hackers try to procrastinate the ideation to the start of the hackathon or pick the problem from the sponsored tracks (not a bad idea but everyone's going to be solving them).

This concept also applies to your professional life, whether you are building a product or the next big SaaS. Solving a shared problem over a personal one will grab more attention and in-turn, more opportunities for you.

Hackathons are free, your time isn't

Sometime down the line, you might get hooked into hackathons. Learn to draw the line and look for bigger fish.

I have organized, participated in, mentored, and judged at countless hackathons. What was important to learn is how vastly the audience and its behavior can change across ecosystems. Student, Web2 & Web3 communities behave in different ways outside the hackathon days which impacts each ecosystem's career and skill pipeline via hackathons.

• If you learned a skill, share it by writing a blog or video tutorial. Day 1 for you is Day 0 for someone else. Sharing any knowledge helps (and builds your reputation online)
• Participated in 5+ hackathons? Try judging, mentoring, or volunteering next. It builds very different skills as a professional and organizers recognize you.
• Working professional? Hackathons are a great place to explore technology outside your domain and not miss office hours. (pick any weekend hacks)

It's important to understand that hackathons are an event format for developer education based on ‘learning by doing.’. It's not the end goal.

You will find bounty hunters who go from hackathon-to-hackathon making a living out of it. This isn't a bad path but it also restricts you from solving bigger ideas (that need more than 24 hours) and growing beyond the scope of four-person devs.

You must have fun.

Super important.

Fun is subjective, so you need to ensure you are having fun in your own ways. Karaoke with teammates or swag-run to all sponsor booths, If it's the organizers' duty to line-up ice-breakers and fun sessions for you, then it's your opportunity to join in and make some memories.

As an organizer, it is worth flexing that we have the most fun in organizing hackathons at Devfolio.

Never Stop Building

This is our motto, and it's also an advice for your career.

Staying technical is important.

A strong hackathon team comprises great devs, a designer, and a presenter. But each should understand (even a little) what’s going on in their project.

Fast forward to your next full-time gig. You may be a product manager, a designer, or a community manager.. It's still relevant to stay technical with your product and ecosystem. This gives you an edge over other non-technical members (more non-tech members, the better you stand out)

Now with LLMs, anyone can vibe-code, might as well use them to learn a little bit of what's happening in your codebase.

I try to participate in hackathons or vibe-code a personal project, when I’ve had a week full of community work..

Oh..and there's one more thing. Flex.

You've got to talk about your hackathon achievements. Not just wins.

Here are some of my wins. In this one year at Devfolio:

• Organized ETHIndia 2024, ETHDenver 2025, Warpspeed 2025
• Organized BlockTrain: world's first Ethereum Hackathon on Train 🚂
• Organized Interfaces 2025 @ IIT Delhi.
• Won StoryAI Hackathon.
• Joined Network School for a month (I'm writing this from there!)
• Became a Devconnect Scholar (See you in Buenos Aires! 🇦🇷)
• Became Head of Community at Devfolio.
• Shipped JesseGPT, Devfolio Week of Shipping
• Ran Organizer101 Show.
• Ran 2586Labs Everyday Essentials Series.
• Running Student Hackathon Grants with AWS

See you at the next hackathon 👋🏻.

🛠 ️Never Stop Building 🛠

Hackathons are where the boldest ideas take shape. Over a single weekend, students come together, form teams, and bring new products into the world. For many, these events are the first taste of entrepreneurship, collaboration, and the thrill of shipping fast.

At Devfolio, we’ve seen first-hand how hackathons can spark lifelong journeys. But we also know the challenges that come with organizing one: funds, resources, and the right support system to bring it all together. That’s where our newest initiative steps in.

Introducing: Devfolio Student Hackathon Grants in association with AWS ✨

Together with AWS, we’re launching a grant program to empower student organizers across India to host world-class hackathons on their campuses.

💰 Grant Amount: Up to USD 500 per hackathon (tailored to scale & needs)

🎓 Who can apply: Student Organizers at universities and colleges across India hosting hackathon between October 2025 and December 2025. (Hackathon not within these dates? Submit interest for 2026 here.

⚡ What’s included: Direct funding support, access to AWS resources and credits, and of course, the Devfolio platfom to streamline applications and project submissions.

But the best part? Organizers and participants will get to tap into the AWS Builder Center: A hub of tools, resources, and learning content designed to supercharge projects. The Builder Center will give every hacker the chance to take their ideas to the next level.

How it works? 🛠️

1. Get Hackathon verified on Devfolio - Get your hackathon set up and verified on Devfolio. Our verification process is thorough and allows us to ensure all the details are available for hackers before your hackathon is announced.
2. Apply for the grant – Fill out the grant application explaining about your hackathon mission, why you want to host it, and how you’ll use the grant.
   Only one representative from the hackathon team should apply to the grant.
3. Get shortlisted – Our team will evaluate applications based on vision, scale, student impact and support scope for your hackathon. We may reach out to get more details.
4. Receive funding & support – If selected, you’ll be onboarded to our grant program which will include sponsorship + support from AWS team during your hackathon.
5. Host your hackathon – Build the event you’ve always dreamed of, with all the resources you need in place.
6. Read the FAQs - We answer most of your questions related to the program in the FAQ, please go through all of them before applying to the program.

There should be no conflict of interest when applying for the grants.

Why this matters 💡

With thousands of students across India building the future, hackathons are the beating heart of the developer ecosystem. By lowering the barrier to organizing them, we’re giving more students the chance to host meaningful events and inspire their peers to build.

AWS brings global expertise and infrastructure to the table. Devfolio brings a decade of hackathon know-how. Together, we want to make it easier for the next generation of student leaders to create experiences that launch ideas, careers, and communities.

Ready to host your hackathon? 🚂

Applications for the Student Hackathon Grants powered by AWS are open now.

👉 Apply to Hackathon Grants here

Let’s make your campus the birthplace of the next big idea.

Warpspeed 2025 landed in Bengaluru on June 21–22. What followed was 24 hours of agentic AI ambition, prototypes that pushed practical boundaries, and a builder frenzy felt from start to finish.

🚀 Flying at Warpspeed

From the first early-morning check-ins to the adrenaline-charged final minutes, Warpspeed 2025 set a new benchmark for intensity and innovation. The energy in the room was palpable. Participants wasted no time diving into ideation, whiteboarding, and rapid prototyping. Fueled by endless cups of coffee and the thrill of competition, teams shipped an impressive spectrum of projects: from voice-based agents that could understand and respond in multiple Indian languages, to developer-centric tools designed to streamline workflow, and robust multi-agent orchestration systems capable of automating complex tasks. What set this year apart was the focus on longevity, since many teams architected their solutions to be more than just weekend hacks, aiming for real-world deployment and scalability.

🎙 Speaker Showstopper Moments

The hackathon’s creative chaos was anchored by a lineup of visionary speakers who brought clarity and inspiration to the builder marathon. Vivek Raghavan (Co-founder, Sarvam AI) and Hemant Mohapatra (Partner, Lightspeed India) delivered a compelling keynote on the future of voice-first, vernacular-friendly AI, emphasizing the need for inclusive technology that bridges India’s linguistic diversity.

Vivek shared behind-the-scenes stories from Sarvam AI’s journey, offering practical advice for teams building for Bharat, while Hemant provided a macro perspective on scaling agentic innovation in India and the unique challenges of building AI for a billion users.

In addition, we also had a fireside chat between Garvit Juniwal from Glean, and Ishan Preet Singh from Lightspeed, where they discussed about the future of agentic AI and what current enterprise workloads can be offloaded to agents.

🛠️ Builders Be Buildin’

As the opening ceremony wrapped and the clock started ticking, something shifted. Laptops flipped open, whiteboards filled up, and the entire venue settled into that unmistakable hum of deep focus. Builders locked in fast. Some paced as they dictated prompts to agents-in-progress, others clustered around tables sketching out multi-agent flows with markers and chai in hand. From solo devs with laser-sharp prototypes to full teams debugging across three terminals, the room was alive with intent.

Even the sharpest minds need a breather. Between models training and bugs squashed, hackers took breaks to rally it out over table tennis and intense foosball showdowns. The rec zone wasn’t just a breakroom. It was where spontaneous doubles tournaments broke out, and rival teams became fast friends over a spin shot. It was proof that great builds don’t just come from code, but from moments of release, laughter, and a bit of healthy competition.

The clack of paddles and the whir of the foosball rods became the soundtrack to new friendships and unexpected collaborations. In between matches, strategies for both games and code were exchanged, and the boundaries between teams blurred as everyone cheered each other on.

The rec zone became a microcosm of the hackathon spirit: fast-paced, energetic, and full of surprises. Here, the pressure of deadlines melted away, replaced by high-fives, playful banter, and the shared thrill of a well-placed shot. In these moments, the community was strengthened, reminding everyone that innovation thrives not just in front of a screen, but in the spaces where people connect, recharge, and inspire one another.

🧠 Mentor Magic

Mentorship at Warpspeed 2025 was more than just guidance, it was true collaboration. Our mentors, drawn from the ranks of senior engineers, startup founders, and venture capitalists at Sarvam AI, Google Cloud, AWS, Magicpin, Base, and Bhindi AI, rolled up their sleeves and got hands-on with teams. They debugged code, brainstormed architecture, and even jumped in for impromptu demos.

Besides the partner mentors, builders also received mentorship from industry stalwarts like Suhas from Localhost, Caleb from Backstage with Millionaires, Tushar from TrueNetwork (also a Warpspeed 2023 Grand Prize winner), and Himanshu from Upsurge Labs. Their feedback was candid and constructive, often sparking pivotal pivots and “aha!” moments that took projects from good to great.

💰 Prize Pot & Partner Bounties

The stakes this year were higher than ever, with over $12,000 in main prizes up for grabs, including Grand Prize, First and Second Runner-Up awards. Explains why everyone was locked in.

But the excitement didn’t stop there - our partners brought their own challenges and bounties:

• Bhindi AI’s “Best Bhindi Usecase”: Recognizing creative applications of agent tooling, five teams each took home $200 for pushing the boundaries of what Bhindi’s platform can do.
• Magicpin, Base, and others issued real-world, product-led challenges spanning retail, logistics, and Web3 interfaces, encouraging teams to tackle tangible industry problems.
• AWS & Google Cloud provided cloud credits, empowering teams to deploy full-stack, production-ready builds without infrastructure limitations.
• Sarvam AI offered access to their multilingual APIs and voice-first frameworks, enabling teams to build conversational agents tailored for India’s diverse user base.

🏆 Winners & Wonders

🥇 Grand Prize ($2,500) - DreamOps
Let AI handle your on-call duties, so that engineers can hit snooze while it saves the day.

🥈 First Runner-Up ($1,500) - PragyanAI
Your multilingual learning buddy, turning complex concepts into fun, interactive experiences.

🥉 Second Runner-Up ($1,000) - PlushieOS
Your sentient emotional AI companion! It provides support and manages daily tasks, all while understanding your unique life context, bundled in the form of a soft toy that can be interacted with.

Check out the rest of the projects here → warpspeed2025.devfolio.co/projects

👀 What’s Next

📸 Photos!
The Warpspeed crew captured every moment - from heads-down hacking to spontaneous snack breaks. The full event gallery can be found here → https://www.playbook.com/s/devfolio/warpspeed-2025 And the BTS will be dropping soon on Devfolio’s X. Relive the energy, spot your team, and share your favorite moments!

🔔 Cheer Livestream: Don’t miss our upcoming Devfolio cheer stream, where we’ll spotlight standout builds and reward contributors. Make sure your wallet is connected so you can claim your well-earned cheers and join the celebration. Crypto cheer guide →

💡 Final Flutter: Forge On

Warpspeed 2025 was powered by sheer passion, creativity, and relentless drive. Every line of code, every late-night brainstorm, and every breakthrough contributed to an unforgettable experience.

Whether you shipped a showstopper or took a strategic pause, remember: the journey doesn’t end here. Keep refining your ideas, keep experimenting, and keep connecting with this vibrant community. The lessons, friendships, and momentum you gained this weekend are just the beginning.

When the next Warpspeed launches, you’ll be the first to know. Until then, stay tuned for updates, showcases, and more opportunities to build the future. You can also check out your next hackathon on Devfolio here: devfolio.co/discover

P.S. - We’d like to give a special shoutout to the team at WeWork Galaxy (especially to Oshin and her team) for helping make Warpspeed 2025 a smooth and seamless experience.

Stay tuned for more updates and interact with the Devfolio community at:

🐦 Twitter                                      📞 Telegram                                    🎮 Discord

Until then, Never Stop Building 🛠️

Back then, I was co-running The SCRIPT Group, a tech club with friends in college — I loved writing code, but what really pulled me in was the community angle. I applied to Devfolio for a Frontend + Community role, but got slotted into Community. Funny how things work out.

Fast forward to today: I’m the Chief of Staff at Devfolio, working across everything from community and operations to marketing, product, and people ops. Here’s how that happened.

🧩 How I Accidentally Started a Career

In November 2020, I volunteered at InOut 7.0.

While everyone else was grinding LeetCode, I was chasing speakers, figuring out Discord bots, and soaking in the energy of people building things they truly cared about.

In December, I was offered an internship under Community & Ops. By July 2021, I was full-time for the same role. The "just trying it out" phase quickly turned into something much bigger.

🛠️ Tried Everything, Became Something

When I joined, I wasn’t a master of anything. But Devfolio had other plans. I was thrown into the deep end — onboarding University Hackathons onto our platform, maintaining our schwag stock and shipping them, emceeing at hackathons, writing tweets and hacker emails, reporting bugs, and handling support requests.

It was a lot to take in, but like clay on a potter’s wheel, I kept adapting, reshaping, and figuring things out as I went.

In Feb 2022, I became Community Lead. My tech background — though I wasn’t actively coding — became a superpower. My initial tasks at Devfolio involved automating a lot of the manual work that came with being a small team. I built systems for generating MoUs, printing shipment labels, and even Discord bots for online hackathon ops.

These eventually evolved into productised features within our platform — working proofs of concept that turned into real tools.

🌍 From Hacker House to Global Stage

When I joined, the team had just moved from the OG 2586 space into OldCRC — a bungalow that felt like home the moment I stepped into it. Total hacker house vibes. We later moved to our current 2586Labs HQ, and I’ve watched the company evolve with each wall we outgrew.

That sense of momentum wasn’t limited to our spaces. Our events started growing too. ETHIndia 2022 and 2023 became the world’s largest Ethereum hackathons. We also started helping other ecosystem builders run theirs — and that took me to Denver, San Francisco, Vietnam, and Kuala Lumpur.

🎯 The Time We Said 'Yes' to Everything (And Pulled It Off Like Pros)

Second half of 2024 was... intense.

• Gen AI Exchange Hackathon by Google
• Base Around The World
• Sahamati BuildAAthon
• ETHIndia 2024

All of these were happening in parallel — with a 12-member company. While one initiative is under execution, we're already charting out the plan for the next one.

Was it hard? Absolutely. But it was a calculated stretch — and we planned for it. Loads of coordination, deep ownership, and a shared drive to make it happen.

Startups are wild like that. You sign up to build something cool and end up running four nationwide and global initiatives at one go.

👥 Chief of Staff: A Role Shaped by Context

This wasn’t an overnight change — over time, I naturally took on the onus of working across teams and stepping in wherever needed.

With 4.5 years of context, I’d built enough familiarity with how we operate that I could jump in and move things forward without second-guessing every step. I’m working towards becoming everyone’s +1 — the person they can rely on when they’re blocked, stuck, or just need a quick reality check. While I’ve only recently stepped into the role officially, my aim is to be that safety net for the team and support the CEO in keeping things moving.

That trust wasn’t handed out — it was built slowly, and I’m grateful that Devfolio sees me as someone who can hold that responsibility.

🕊️ Remembering Shakti

As Nash — our Co-founder and Head of Design at Fold — put it beautifully during the ETHIndia 2022 opening ceremony:
"Not only is it important that we keep the people we're building for in mind, but it's also important that we keep in mind the people who built for us."

That line stuck with me. It made me think of Shakti Goap (1992–2021), Devfolio’s Founder & CEO, and the first person who truly took a bet on me. I only worked with him for six months, but those months laid the groundwork for how I show up every day.

There’s a Slack message he once sent me to celebrate a tiny win — I’ve held on to it since. A small moment that reminds me to honour progress, however minor it seems.

"Never Stop Building" wasn’t just a motto for Shakti. It was how he moved through the world. That energy continues to guide everything we do.

🤝 The People Who Made This Journey Worth It

Denver — who was Community Lead when I joined and is now our CEO — his growth has mirrored mine, and he’s been a major force in shaping how I work.

Akash, the Co-Founder and CEO of Fold, is the calm in the chaos — the person I go to when I need perspective.

And the rest of the Devfolio team? Chaotic, passionate, talented, meme-fueled, high-output machines. Wouldn’t trade this crew for anything.

🚀 Why Startups Hit Different

There’s no better playground than a startup if you want to learn, build, and break stuff (in a good way).

I’ve written copy, made platform changes, built Notion dashboards, managed projects — sometimes all in one day. No red tape. No "that’s not your job."

Even a single Telegram reply can spark something meaningful. Every little action counts. That’s what I love most about startup energy.

🔮 We're Just Getting Started

Devfolio’s mission is to redefine economic opportunities for builders — and we’re only just getting warmed up.

Everything we’ve built so far has been the foundation. There’s so much more we want to do — better tools, wider access, deeper impact. And the same hustle that got us here is going to take us further.

This isn’t a look back. It’s a gear-up-for-what’s-next.

🔚 Closing

If you’ve made it this far, thank you for reading my story. It’s been a wild 4.5 years — and we’re nowhere close to done.

Whether you're a student, a builder, or someone still figuring it out — I hope this gave you a glimpse of what’s possible when you just keep showing up.

Never Stop Building 🛠️
Say hi: @AniketRaj314 | aniketraj.me