Build for the
real world.
Autonomous agents, rooted Android and Linux tooling, computer vision and interfaces that feel faster than they should. I care about systems that keep working after the demo ends.
See the workSystems
& strikes.
I am Pranav Dwivedi. I build software that has to work outside a demo, and I play cricket for a team that expects to win. The two disciplines share the same standard: stay composed, read the situation, execute.
One person.
Two outputs.
Software and sport are not separate identities. They are two places where the same habits show up: preparation, pressure and the willingness to take the last over, or the last bug, yourself.
Build for the
Play under
pressure.
Captain and all-rounder for Destroyers CC. 3,289 runs, 118 wickets and three consecutive ABV Memorial titles. The record is public and the scorebook does not negotiate.
Read the recordSoftware has
a new home.
Stargaze is the independent software branch of my work. It brings the agents, tools and interfaces under one name. The first public release is in private build.
Enter StargazeFacts, not
a manifesto.
The details that matter if you are checking the record, the stack or the context.
CricketCaptain / all-rounderDestroyers CC / No. 07
SoftwareAutonomous systemsAgents, Android, Linux, vision
Record3,289 runs / 118 wicketsRDCA circuit / 2021–2026
HonoursThree straight titlesABV Memorial / 2024–2026
StackPython / Kotlin / TypeScriptZig, FastAPI, MediaPipe, Firebase
A short
timeline.
No invented milestones. Just the marks that already exist.
- 2021First recorded seasonRDCA circuit
- 2024First ABV Memorial title4–1 final
- 2025Back-to-back title5–0 final
- 2026216* off 56 balls and a third title3–2 final
- 2026Stargaze enters private buildRelease 01 / soon
The way
I work.
Three habits that show up in both the software and the cricket. They are not slogans; they are the checks I use when a build or an innings starts to drift.
01Understand the constraintFind the real limit before adding another layer. The hard part is usually smaller and more specific than it first appears.
02Build the useful versionLocal first, quiet by default, working outside the demo. A smaller system that survives real use beats a larger one that only performs.
03Stay composedPressure is information, not an emergency. Read the situation, take the percentage option, and leave the next person a clean handover.
A working
biography.
The short version, written for someone who has ten minutes.
I build software for the moments after the demo. The useful test is whether a system still makes sense on a bad connection, an old phone, or a day when the person using it is tired. That is where most of my attention goes.
The other half of the work is cricket. I captain Destroyers CC and bat in the middle order. The field teaches a different kind of feedback: the ball does not care how elegant the plan was. You read the situation, choose, and live with the result.
This site is the public index for both. The software lives under Stargaze. The record lives in the scorebook. The rest is context, notes and the occasional argument with a compiler.
The
scorecard.
The numbers that are already on the record.
Runs3,289RDCA circuit / 2021–2026
Wickets118Across formats
Best innings216*Off 56 balls
TitlesThree straightABV Memorial / 2024–2026
ShirtNo. 07Destroyers CC
RoleCaptain / all-rounderMiddle order / pace
Two disciplines,
one test.
The habits transfer even when the tools do not.
Before the first ball or the first commit, find the constraint that will decide the outcome.
The best option is rarely the most impressive one. It is the one that leaves room for the next step.
A plan is only useful when it survives contact with a device, a pitch or a person who has never seen the demo.
Pressure is information. It tells you where the system is thin and where the next adjustment belongs.
The next person should be able to pick up the work without a meeting. That applies to code and to an innings.
One good over is not a season. One clean build is not a product. The loop is the work.
The stack,
in public.
Tools I reach for, not a logo wall.
Python Kotlin TypeScript Zig FastAPI Android Linux Termux OpenCV MediaPipe Firebase HTML / CSS JavaScript Git
The common thread is small systems that can be read, replaced and debugged without a platform team.
What I
optimise for.
The qualities I check before calling something finished.
- It works without a live demo and a stable connection.
- A new person can find the entry point in under a minute.
- The error path is as considered as the happy path.
- The interface says what it is doing instead of hiding behind a spinner.
- The build can be replaced in pieces, not all at once.
- The record can be checked without asking me to explain it.
A working
week.
A rough shape, not a productivity system.
MONRead the system
Find the real state of the project before adding another layer.
BuildTUEMake the path
Get one useful route working end to end, however narrow.
BuildWEDTest on device
Move from the desk to the phone, the club laptop or the old machine.
VerifyTHUCricket
Training, a match or a long look at the record. The body keeps its own changelog.
FieldFRICut scope
Remove the feature that makes the release harder to explain.
EditSATLong run
The unglamorous pass: cleanup, notes, handover and the next open question.
CloseThe cricket
brain.
What the middle order is actually doing.
The first job is not a shot. It is information about what the ball is doing.
Captaincy is resource allocation under time pressure. Every fielder is a bet.
A good over has an intention beyond keeping the ball away from the bat.
The scoreboard, the wicket and the bowler all change the correct answer.
The ordinary skill, repeated under pressure, is usually the difference.
The result is data. The process is what you can actually improve.
Software
principles.
Four rules that survive most stack changes.
01Local firstThe useful version runs on hardware you control. The cloud is an option, not the foundation.
02One job per toolSmall services are easier to explain, replace and debug when the system is under pressure.
03Visible stateThe interface should show what the system knows, what it is doing and what it will do next.
04Boring foundationsFiles, processes and sockets before a new platform. The least surprising layer lasts longest.
Constraints
I like.
Limits that make the work more specific.
01Offline
If it cannot work without a connection, the design has to say so early.
Product02Old hardware
A build that runs on the spare phone is usually a build with fewer hidden assumptions.
Device03One screen
A narrow interface forces a decision about what matters now.
UX04No backend
Static pages and peer-to-peer paths remove a class of operational problems.
Web05Root access
Android becomes a real computer when you can see the system underneath.
Android06A hard deadline
A date turns a list of ideas into a release with an edge.
DeliveryCurrently
learning.
The topics with a live notebook open.
01Agent evaluation
How to tell whether a tool-using agent is actually better, not merely busier.
02Zig
A smaller language for the parts of systems work where explicit control matters.
03Sports biomechanics
What the body does before the bat speed shows up on camera.
04Interface history
The older patterns that explain why modern software still feels the way it does.
05Local models
Routing, memory and the practical limits of running intelligence on a phone.
Reading
shelf.
Subjects rather than a performance of taste.
01Distributed systems
Consensus, failure modes and the cost of pretending the network is reliable.
Notes02Sports writing
The best match reports explain pressure without turning it into mythology.
Notes03Interface design
Typography, hierarchy and the small decisions that make software feel deliberate.
Notes04Systems programming
Memory, protocols and the places where a high-level abstraction is doing too much.
Notes05Biography
How people actually make decisions when the public story is tidier than the life.
NotesThe
workstation.
The physical setup behind the output.
Long-form builds, editing, interface work and the place where the site is tested first.
Rooted phone, Termux and the honest test of whether a tool fits in a pocket.
Small services, local models and the environment where the boring foundations live.
Most of the work starts here. The GUI is allowed in when it earns its place.
A phone camera and pose estimation, pointed at a real batting stance.
Diagrams, match notes and the questions that are not ready to become code.
Away from
the screen.
The inputs that are not a framework.
Cricket takes the largest share. Training, matches and the ordinary maintenance of a body that has to show up for a long season. The club is also a useful reminder that a team is a system with people in it.
The rest is quieter: reading, walking, a notebook and the kind of conversation that changes the shape of a problem. None of it is content. It is the raw material that keeps the work from becoming self-referential.
The
colophon.
How this page is put together.
01Type
Mona Sans for the display and body voice, with a serif italic used as the accent.
02Build
Hand-written HTML, CSS and JavaScript. No framework and no build step in the current build.
03Motion
A small motion layer for reveals and parallax, with a reduced-motion path.
04Images
WebP assets, local fonts and no third-party image host.
05Hosting
Static files. The site can run from any ordinary web server.
06Source
The public code lives on GitHub. The private systems stay private until Release 01.
Open
questions.
Things I have not finished answering.
01How local?
How much of a useful agent can live on a phone before the cloud becomes an honest requirement?
Stargaze02What proof?
Which signals actually show that a sports-vision model is useful to a player, not only accurate on a test set?
Vision03Which interface?
How much of an agent's reasoning should be visible before the interface becomes noise?
Design04What next?
Which archive project deserves a full rebuild rather than another patch?
Work05When to stop?
How do you know a system is finished enough to leave alone for a season?
CraftA note on
the record.
The scorebook has the final word.
“The record is not the identity. It is the evidence that the work happened.”
Pranav Dwivedi / Destroyers CCThe numbers on this site are a summary. The verified registry and the club dossier are linked on the Network page.
A short
conversation.
If you want the longer version of any part of this page, send a note. A specific question is easier to answer than a broad introduction.
Send a noteVersion
notes.
What changed in this public build.
2026Multipage site
The editorial rebuild, the work ledger and the cricket record moved under one roof.
Live2026Stargaze
The software branch entered private build with a first-release scope.
Private2025The record
Back-to-back ABV Memorial titles and a larger public archive of the club.
Archive2024First title
The first ABV Memorial win and the start of the current run.
Archive