Every enterprise system arrives with a document that says what it does. The document is usually written before the system is finished, by people who want it to be true, and it is read by people who have no time to check. Most of the time the gap between the two goes unnoticed until something breaks: an access rule that was described but never enforced, a process that works in the demo and fails on a clean server, a number on a dashboard that nobody can reproduce. The expensive failures in enterprise software are rarely the ones nobody predicted. They are the ones somebody wrote down as solved.
Hari Krishna Bethanaboina has spent more than two decades closing that gap for a living. A Lead Solutions Architect at Martin Marietta Materials, one of the largest publicly traded aggregates companies in the United States, he leads Oracle Fusion Cloud Procurement and JD Edwards Capital Asset Maintenance programs governing more than $8 billion in capital assets across more than 400 sites and a supplier base of over 16,000 vendors. Before that he delivered enterprise transformations across the United States, Europe, the Middle East, Asia and Africa, for Fortune 500 corporations, fast-growing private companies and global merger integrations. He is an IEEE Senior Member, a Full Member of Sigma Xi, a Distinguished Fellow of the Soft Computing Research Society and an Oracle ACE Associate, and he reviews research for IEEE, Elsevier and Springer Nature.
When Hackathon Raptors asked him to judge DOGFOOD 2026, he did not stop at reading the submissions in his batch. He ran them, and then he tried to break them.
Bethanaboina treats a project’s documentation as a set of claims to be tested, and he scores the gap between what a system says and what it does under a probe.
A Hackathon Where the Product Is the Judge
DOGFOOD 2026, organized by Hackathon Raptors and held online from September 26 to September 29, 2026, gave every team the same 72-hour brief: build the self-hosted platform that would run a hackathon, from registration and team formation through submissions, judging and results. The name was the point. The winning platform is meant to be forked and run for a real event, so every team was building the kind of system that would one day judge them.
The brief set a ladder of four tiers, from core accounts and submissions up through judging, community voting and stretch features, and it set two rules that most hackathons never attempt. The first was operational: a single docker compose up had to produce a working portal on a laptop, with no cloud account and no hosted service, and the system had to keep working with the network switched off once it was built. The second was about integrity. Role isolation had to be enforced in the backend, not painted on in the interface, and any normalization of judges’ scores had to be documented and defensible.
Scoring followed four weighted criteria: Tier Completion and Correctness at 40 percent, Judging Integrity at 25 percent, Adoptability and Operability at 20 percent, and Code Quality and Innovation at 15 percent. The brief also rewarded honest gap reporting. A team that claimed a tier it had not built was meant to lose more than a team that said plainly where it stopped.
For an architect whose career includes keeping procurement and inventory running on offshore drilling rigs without continuous connectivity, the offline rule was not an abstraction. At Shelf Drilling he designed a hybrid online and offline ERP model that kept 38 rigs in 13 countries operating, a rollout Oracle recognised with its Best Implementation Award in 2014. He knows what it takes for a system to start, run and stay consistent when the network is not there to help, and he knows how often a vendor’s assurance that it will has not been tested.
Running the Code Instead of Reading It
Bethanaboina’s batch, Batch 10, held 14 submissions. His written notes show a method that is closer to an acceptance test than a review. On one submission he recorded the full procedure: “I built it and ran it against local PostgreSQL, then ran the official checker, live probes and a headless browser pass.” On another: “I ran it on Python 3.12 with the pinned dependencies against local PostgreSQL, using the same migrate, seed and start commands as the container. I then ran the official checker, the project’s tests, live probes of the full event flow and a headless browser pass.”
He was also careful to say where his own test fell short. On the first of those submissions he added: “Two caveats: docker compose up is untested (no Docker here), and the Prisma 5 engine download is blocked in my sandbox, so I ran a scratch copy on Prisma 6’s JS engine with migrations applied by psql. Route code was unchanged.” That sentence matters more than it looks. A review that names the limits of its own evidence can be checked and corrected. A review that hides them asks to be trusted, which is the same thing he was refusing to give the teams.
This is the posture of someone who has spent years on the receiving end of system integrations. When Covidien was acquired by Medtronic in a $49.9 billion transaction, Bethanaboina designed the bi-directional integration between JD Edwards and SAP that kept the global supply chain running through the transition. Integrations at that scale do not succeed because each side’s documentation is accurate. They succeed because someone tests every assumption at the boundary before the business depends on it.
Authentication Is Where Claims Go to Die
The pattern that ran through Bethanaboina’s lowest marks was not missing features. It was security that existed in the documentation and nowhere else.
On one submission he wrote that “authentication is effectively absent: I found five separate ways to become any user, including organizer and platform owner, which makes its score-privacy claim hollow.” The final clause is the important one. The project had claimed that judges could not see each other’s scores. That claim was true in the interface and meaningless in practice, because anyone could become any judge. A privacy guarantee that sits on top of broken identity guarantees nothing.
Another entry, he noted, “has a working judging API whose role checks and score validation hold, but it replaced the shared fixture data with its own, has a one-request privilege escalation, and its Docker deployment does not serve the real interface.” A third was “mostly a read-only viewer over the fixture data plus one scoring form,” and he added that “the documented normalization does not exist in the code, and as shipped anyone can take over the organizer account.”
None of these findings came from reading the README. They came from sending requests the interface would never send and watching what the server did with them. That is the only test that matters for role isolation, and it is why the brief insisted on enforcement in the backend. Bethanaboina’s experience bears this out. At Merck Sharp and Dohme, where he worked across 20 countries in Europe, the Middle East and Africa, he led a full redesign of the enterprise security model after vulnerabilities were found following go-live. Security that is discovered to be missing after launch costs many times what it would have cost to test before. A hackathon is a cheap place to learn that, and his notes made sure the teams learned it.
When the Documentation Outruns the Build
The second recurring finding was quieter but just as consistent. Several submissions described more than they delivered.
He wrote of one project that it “is an ambitious hackathon judging platform with a broad backend, but it has some security gaps,” and that its “documentation overstates what works.” Of another, that “it is largely a read-only viewer over the fixture data: most of Tier 1 is not built, there is no real login, and several headline features are less than their names claim.” A third, he noted, “follows the hackathon spec, passes the official checker and has real Tier 1 flows, but its judging core is broken underneath and there is a critical login gap.”
The last example shows why the official checker alone could not settle a score. The checker confirmed that a submission followed the published structure and handled the shared fixture data. It could not confirm that the judging logic underneath was sound. Bethanaboina’s probes went to the layer the checker could not reach.
He applied the same standard to submissions that could not run at all. One, he wrote, “does not run, the backend fails to import, the frontend’s production build fails, and none of the hackathon’s required files are present. It looks like a single branch export (mrin-frontend) rather than the full project.” Another “is a thin demo, a small, tidy FastAPI backend whose role checks hold, but it cannot run from a fresh clone, has no tests, and its frontend only works against hand-prepared data.” Even in a failing submission he recorded what did work, here the role checks, before recording what did not. That balance is what makes a review useful to the people who receive it.
Honesty as a Scored Property
Against that background, the submissions Bethanaboina rated highest stood out for one shared quality: their claims matched their behaviour.
He gave three projects his top marks on tier completion, adoptability and code quality. Rubric, from Team AM, was the clearest case. “Rubric is a strong submission,” he wrote. “It follows the hackathon spec, passes the official checker, and its Tier 1 and Tier 2 flows worked end to end under live probing with clean access control. Its claims are also the most honest.” Rubric did not claim the top of the ladder. It claimed what it had built, and what it had built held up. It finished seventh of 194 ranked projects in the final standings, among the strongest in the field.
Jengine, from team MOSAIC, earned the same marks. He described it as “a well-architected, heavily tested judging platform whose security held up under live probing,” and was specific about its faults: “minor gap for a broken post-sign-in page and a few gaps between the docs and reality.” A strong score with named defects is more useful to a team than a strong score alone, because it tells them exactly what to fix next.
Raptorgate, from team Pink Cloud, showed the other side of his method. “This is a strong entry,” he wrote. “The backend is careful and well tested, the tier claims are honest, and every access-control probe I ran held.” Then he named the thing that held it back: “What holds it back is operability: an organizer cannot run a new event end to end from the product, and the freshly seeded portal has dead links until a hidden step is done.”
That is the Adoptability and Operability criterion expressed as a single observation. A system that passes every security probe can still fail the person who has to run it on a Monday morning. A hidden setup step is exactly the kind of defect that never appears in a demo and always appears in production, because the demo is run by the people who know the step exists. In enterprise rollouts, where the people who operate a system are rarely the people who built it, this is one of the most common reasons a technically sound platform is quietly abandoned.
What an Enterprise Architect Sees in a 72-Hour Build
It would be easy to treat a hackathon as too small to say anything about enterprise software. Bethanaboina’s notes suggest the opposite. The defects he found in Batch 10 are the same defects that cost large organizations money every year, compressed into a form that is easy to see.
Identity that is described but not enforced. Documentation that runs ahead of the build. Normalization logic that appears in the design document and not in the code. Deployments that serve something other than the real interface. Systems that only work against data the team prepared by hand. Each of these, at enterprise scale, becomes a failed audit, a security incident, a disputed number or a stalled rollout. Each of them, at hackathon scale, becomes a line in a judge’s notes that a team can fix in an afternoon if someone takes the time to find it.
His own record shows why he takes that time. Projects he led have been recognised with Oracle’s Best Implementation award and featured in Oracle Profit Magazine, and he has published research on artificial intelligence, predictive maintenance and supply chain digitization in peer-reviewed technology journals. He serves as a session chair for international IEEE conferences and on the judging committee for the IEEE Computer Society Emerging Technologies Grant Program. Across those roles the common thread is evaluation: deciding whether a piece of work does what it says, and saying so in a way the author can act on.
DOGFOOD was built to reward exactly that kind of judgement. Its scoring adjusted for judges who scored high or low across the board, so a harsh but consistent reviewer did not distort the field, and its published results show each project’s rank range rather than a single number. Within that design, what an individual judge adds is evidence. Bethanaboina’s batch arrived with evidence attached to almost every score: what he ran, what he probed, what held and what did not.
The Lesson for Builders
For the teams in his batch, the message in his notes is consistent enough to state plainly. Do not claim what you have not tested. Test identity and access from the server’s side, by sending the requests a hostile user would send. Make the system start from a fresh clone, with the documented commands, on a machine that has never seen it before. Tell the reader where you stopped.
These are not hackathon rules. They are the rules that decide whether enterprise software survives its first year in production, and they are the rules Bethanaboina has applied on rigs without connectivity, through multibillion-dollar integrations and across hundreds of sites. DOGFOOD gave him 14 small systems and 72 hours’ worth of claims to test. He tested them the way he would test a system his own organization was about to depend on, and the teams that built honestly were the ones that came out on top.
The most valuable sentence in his batch may be the shortest one. Of the submission he rated among the best, after all the probing was done, he wrote: “Its claims are also the most honest.” In a field where so much was claimed, that was the highest compliment available.
DOGFOOD 2026 was organized by Hackathon Raptors. Results and the full public scoring record are published at dogfoodhack.com/winners.
