We build web tools that do one job.
ESPYCRUX is a small product studio in India and the home of everything it ships — a tools site, a game hub and a publication, each on its own address. Narrow, well-made, no account walls, and no feature list written for a pricing page.
We also write about the work: the performance problem that took a week, the tool we dropped, the decision we got wrong. Specifics rather than summaries, and only about things we actually built.
The network
Six public properties, each on its own address. Three are live and usable today; three are unfinished and are labelled that way rather than quietly linked.
- Smart Tools Today — smarttoolstoday.com (live) — Twenty-six free single-purpose web tools — formatters, converters, generators and calculators — that run entirely in your browser.
- ESPYCRUX Games — game.espycrux.com (live) — A game hub of five original browser games with live leaderboards, player stats and clans — every title written in-house rather than embedded from elsewhere.
- iBlog — iblog.espycrux.com (live) — The network's general-interest publication — lifestyle, beauty, technology and current affairs, written for a wider audience than the engineering notes published here.
- Ecom — ecom.espycrux.com (in development) — A storefront project in early development. Nothing is live yet, so there is no link — this entry exists so the roadmap is visible rather than hidden.
- Forum — forum.espycrux.com (in development) — A community forum for players and users across the network. Installed but not opened — there are no discussions behind it yet, so there is no link.
- iShowcase — ishowcase.espycrux.com (in development) — A showcase for finished work across the network. Nothing is behind it yet, so there is no link — the entry is here so the plan is visible.
The six above are the whole network. They have not always been: several other subdomains were started over the past year and left unfinished, and rather than keep them running as empty addresses with our name on them, we are closing them. That is a deliberate decision and the reasoning is written up in full in "Running a network of small sites from one studio" — starting a site takes five minutes, and everything after that is the actual work.
How we build
- Fast by default: Every page is measured on a mid-range phone, not a workstation. If an interaction cannot stay under a tenth of a second there, it gets rebuilt rather than shipped.
- Nothing leaves the browser: Where a tool can run client-side, it does. What you paste into a formatter is not uploaded, not logged and not stored — because it never reaches a server at all.
- No account walls: You should not have to register to use a calculator. Sign-in exists only where an application genuinely needs to hold your work between visits.
- Built mobile-first: Layouts are designed at phone width and expanded outwards, so a small screen gets the real interface rather than a compressed desktop one.
- Accessible on purpose: Keyboard navigation, visible focus, checked contrast, and every animation on the site disabled when the system asks for reduced motion.
- Kept working: A small number of applications maintained properly beats a long list left to rot. Fixes go out as problems surface, not on a release calendar.
Recent writing
- Five browser games, and what each one is for — We did not plan a genre spread. We built five games one at a time, and only afterwards noticed what they had become: not a difficulty ladder, but…
- Scroll-driven animation with no JavaScript at all — We rebuilt our site's scroll animation on CSS scroll timelines and deleted every scroll listener, every animation library call and roughly forty…
- What a leaderboard does to a casual game — We added leaderboards after the games were built, not before, and it changed how people played rather than how many played. Here is what a scoreboard…
- Agentic AI and the shape of small-team work — When a model can take actions rather than only produce text, the thing you hand over stops being a question and becomes a task. That sounds like a…
- A practical Core Web Vitals checklist for small product teams — Most Core Web Vitals advice is written for teams with a performance engineer. This is the checklist we actually work through on a small studio's…
- Knowing when a game is finished — An endless arcade game has no end state, which means it has no natural moment where the work stops. We have hit that problem five times. Here is what…