Inside the UTHAKKAN Ecosystem: How PdfPix, ToolPix, and ZyRace Are Built

It is tempting to describe a group of products as an ecosystem, which usually means they share a brand and a login. What these products actually share is narrower and more useful: a single architectural rule, applied consistently.

The rule is that an operation runs in the browser unless there is a specific, defensible reason it cannot. Not 'runs in the browser where convenient', and not 'runs in the browser for the free tier'. The default is local, and any exception has to justify itself.

The value of a rule like this is that it settles decisions before they become arguments. Should there be a user account? No, because there is no server-side state to attach it to. Should there be a file size limit? No, because there is no server cost per file. Should there be a retention policy? There is nothing to retain. Each of those answers falls out of the architectural decision rather than being negotiated separately.

It also imposes real costs. Some features become impossible, others become considerably harder, and the ones that involve large models cannot be done locally at all. Those costs are visible in the products, and the honest response is to be clear about them rather than to paper over them.

PdfPix is the document arm, and it is the product where the client-side constraint is most natural, because PDF manipulation is a structural rather than a computational problem.

The core operations read a file into memory as a byte buffer, parse the object graph and cross-reference table, modify the structure, and write a valid file back out. Merging remaps object identifiers across documents. Splitting extracts page subtrees. Reordering rebuilds the page tree. Rotation, cropping, watermarking, and pagination all add drawing operations to page content streams. None of this needs a server, and all of it runs in milliseconds on ordinary hardware.

Rendering is handled separately by PDF.js, which draws pages to a canvas. That is what produces the thumbnails you see while selecting pages, and it is also the mechanism behind image extraction and page rasterisation. Rendering is the more expensive of the two paths, which is why thumbnail generation is progressive rather than blocking.

The exceptions are worth naming. The AI-assisted features, which cover summarisation, translation, and text cleanup, require a model, and a model requires the text. Those features transmit extracted text to a server-side endpoint, which is a materially different data flow from the rest of the product. It is documented as such because a uniform privacy claim would be inaccurate.

The security tools deserve a separate note, because they are where users make assumptions. The redaction guide explains that our redaction tool masks content rather than removing it, and why that distinction matters. The signing guide covers when a simple electronic signature is sufficient and when a certificate-backed signature is required. Being precise about these limits is more useful than implying that every operation is equivalent.

ToolPix applies the same constraint to a different problem class. Developer and general utilities are mostly text processing: formatting, converting, encoding, validating, generating, and transforming structured data.

The interesting difference from document work is the data volume. A JSON file, a log export, or a dataset can be far larger than a typical PDF, and the operation is usually a pure function from input to output with no rendering involved. That makes the work cheap but it makes memory management the constraint, since the entire input and output live in the tab.

It also makes the privacy argument stronger rather than weaker. Developers routinely paste configuration files, credentials-adjacent strings, and internal identifiers into online utilities without thinking about it, which is a poor habit when the utility is a cloud service logging every request. A local tool removes that category of accident entirely, and it also means the tool works on a locked-down corporate machine with no outbound access.

Interactive graphics stress a completely different part of the platform, and that is why it is a useful product to build alongside the others.

Where document tools care about correctness and developer utilities care about throughput, a real-time game cares about frame timing. The relevant constraints are the size of the render loop, the number of draw calls, the cost of uploading geometry to the GPU, and the latency between input and visible response. None of these matter in a merge operation, and all of them dominate here.

The techniques transfer in one direction more than the other. Optimisation habits learned in graphics work, such as batching work, avoiding per-frame allocations, and moving heavy computation off the main thread, are useful in document tools too. Web Workers in particular appear in both: rendering thumbnails for a hundred-page document is the same kind of problem as keeping a game loop smooth while something expensive happens in the background.

The constraint also shows up in the same way. A game that requires a server for multiplayer has a hosting cost and an availability dependency. A local multiplayer game has neither, and it works on a plane. That is the same reasoning as running a merge in the browser, applied to a different medium.

It would be dishonest to describe these products as having no backend. The server does three things, and it is worth being specific about each.

First, it delivers the application itself. The products are statically exported, so the server is serving files, which is cheap and cacheable. Second, it provides a narrow API surface for the features that genuinely need a model. That endpoint accepts text, forwards it to a model provider, and returns the result without persisting it. Third, it handles the ordinary operational concerns: redirects, headers, and the security policies that control what the page is allowed to load.

The boundary is what matters. No user document is stored. No account database exists. No file passes through the server for structural operations. The API endpoint exists because a capability requires it, and it is documented because users deserve to know which features use it.

That is a different architecture from the conventional one, and it produces a different set of trade-offs. There is no per-user storage cost and no retention obligation, but there is also no server-side processing power to draw on when a task needs it. The products are shaped by that exchange, and being clear about it is part of the design rather than an afterthought.

The products share engineering lessons and infrastructure, but they deliberately do not depend on each other.

A conventional product family encourages coupling, because a shared account system increases the value of each product and the cost of leaving. That is a real business advantage and it is precisely the mechanism these products are built to avoid. If you want a PDF merged, you should not have to create an account, and you should not have to care that a game exists.

The practical result is that each product has to justify itself on its own merits, which is a harder standard and a better one. It also means a product can be retired without stranding users of the others, and that new work can be judged on whether it is useful rather than on whether it feeds a funnel.

The shared thing is the method. Whatever the next product is, it will be built against the same question: can this be done in the browser, and if not, why not?