Building a platform containing more than a hundred calculators and utilities is a completely different engineering problem.

When I started building Navorika, my original idea was straightforward: create useful online tools that load quickly, don't require an account, and process data locally in the browser whenever possible.

The first few tools were simple.

Then the project grew.

Finance calculators were followed by PDF utilities, image tools, developer utilities, construction calculators, networking tools, and other everyday calculators.

At that point, I discovered something important:

«The difficult part isn't building the 10th tool. It's designing a system that can still make sense when you build the 100th.»

This article covers some of the lessons I've learned while building the platform with Next.js and TypeScript, particularly around architecture, browser-side processing, validation, privacy, routing, and scaling a large collection of relatively small applications.

1. A Tool Is More Than a React Component

My early mental model was roughly:

/tool

├── title

├── description

├── form

├── calculation

└── result

That works when you have five tools.

It becomes painful when you have 100+.

Every tool actually has several responsibilities:

Tool

├── Metadata

├── Category

├── Route

├── UI

├── Input validation

├── Processing logic

├── Result formatting

├── Explanatory content

├── Related tools

├── Structured data

└── Search metadata

If each page implements these independently, inconsistencies appear very quickly.

One page uses one breadcrumb structure.

Another uses a different heading hierarchy.

One calculator validates negative numbers.

Another doesn't.

One page has related tools.

Another forgets them.

The solution for me was to stop thinking about the project as a collection of pages and start thinking about it as a registry of applications.

Conceptually, a tool can be represented like this:

interface Tool {

slug: string;

name: string;

description: string;

category: string;

keywords: string[];

relatedTools?: string[];

}

The actual architecture can contain much more information, but the important idea is that the tool's identity lives in structured data rather than being recreated independently across multiple parts of the application.

Once this becomes the source of truth, many things can be generated from it.

Registry

│

├── Tool routes

├── Category pages

├── Search

├── Related tools

├── Sitemap

├── Navigation

└── Discovery pages

This was probably the biggest architectural lesson from scaling the project.

2. Browser-Side Processing Is Surprisingly Powerful

Another decision that influenced the architecture was trying to process information locally whenever the task didn't genuinely require a server.

Consider JSON formatting.

A basic formatter doesn't need an API.

The browser already provides what we need:

const parsed = JSON.parse(input);

const formatted = JSON.stringify(parsed, null, 2);

That means the workflow can simply be:

User input

↓

Browser

↓

JavaScript parser

↓

Result

instead of:

User input

↓

HTTP request

↓

Application server

↓

Processing

↓

HTTP response

↓

Result

The first architecture has several advantages.

There is no network round trip for the calculation.

The server doesn't need to process the user's data.

The infrastructure has less work to do. And for many tools, the user's working data never needs to leave the device.

I implemented this approach in tools such as the JSON formatter on "Navorika" (https://navorika.com/tools/universal-json-studio), where parsing and formatting happen in the browser.

The same principle applies to many small utilities:

- Base64 encoding

- URL encoding

- UUID generation

- timestamp conversion

- JSON comparison

- CSV conversion

- image manipulation

- certain PDF operations

- text transformations

- subnet calculations

This doesn't mean every application should be client-side. It means we should ask a useful question before creating an API:

«Does this operation actually require a server?»

Often, the answer is no.

3. Privacy Can Be an Architectural Property

Privacy statements are often treated as website copy.

But while building browser utilities, I started thinking about privacy differently.

It can be an architectural consequence.

Suppose someone wants to format this:

{

"customer": "example",

"order": 1428,

"status": "pending"

}

If the formatter sends the JSON to a server, the application operator potentially receives that information.

If "JSON.parse()" and "JSON.stringify()" run locally, the application doesn't need to receive it at all.

That's a meaningful distinction.

The same reasoning becomes more interesting with tokens.

A JWT typically contains three dot-separated components:

header.payload.signature

The header and payload use Base64URL encoding.

You don't need to send a token to a server simply to inspect those encoded components.

The browser can decode them locally.

But there is an important security distinction here.

4. JWT Decoding Is Not JWT Verification

This deserves special attention because it's an easy mistake to make when building developer tools.

Decoding a JWT answers:

«What does this token contain?»

Verification answers:

«Should I trust this token?»

Those are not the same question.

You can decode:

xxxxx.yyyyy.zzzzz

and display something resembling:

{

"sub": "123",

"role": "admin"

}

That does not establish that the token is authentic.

The signature still needs to be verified using the appropriate cryptographic key and algorithm, and claims such as expiration, issuer and audience may need validation depending on the application.

A utility should therefore never imply:

Decoded successfully = valid token

The correct relationship is:

Decode

↓

Inspect structure

Verify

↓

Establish authenticity

↓

Validate relevant claims

This influenced how I designed the JWT utility in my developer-tool collection: decoding is explicitly presented as inspection rather than signature verification.

It also taught me a broader lesson.

A good developer tool needs to explain what its result does not mean.

5. Validation Matters More Than the Formula

Calculators often look deceptively simple.

Take a basic formula:

const result = width * length * depth;

Writing that line is trivial.

The real work is everything around it.

What happens when:

width = -5

length = 0

depth = "hello"

What units are being used?

Can the user enter decimals?

What is the sensible maximum?

What should happen when a required field is empty?

Should zero be valid?

Does the output require rounding?

A production calculator therefore looks more like:

Input

↓

Type validation

↓

Range validation

↓

Unit normalization

↓

Calculation

↓

Precision handling

↓

Result

↓

Explanation

As the number of tools increased, validation became one of the biggest quality differences between something that merely looks like a calculator and something that is actually useful.

6. Some Tools Should Not Be Published Yet

This was a harder lesson.

When building a large platform, there is a temptation to increase the tool count quickly.

But a page with a button that produces unreliable output isn't a tool.

It's technical debt with a URL.

For example, imagine creating a code formatter.

A simplistic implementation might manipulate whitespace using regular expressions.

That may work on trivial input.

Then someone gives it:

const message = "hello world";

An aggressive whitespace transformation could modify the string itself.

The interface still looks correct.

The button still works.

The output is simply wrong.

Parser-dependent tasks should use appropriate parsers.

That led me to adopt a simple principle:

«If the correct processing engine isn't ready, temporarily disabling the functionality is better than pretending it works.»

This sounds obvious, but it becomes increasingly important when the number of applications grows.

7. Tool Relationships Become a Graph

Once I had dozens of utilities, another problem appeared.

Categories weren't enough.

Consider JSON.

A developer might start with:

JSON Formatter

and then need:

JSON Schema Validator

or:

JSON → CSV

or:

JSON Diff

These tools belong to the same category, but more importantly they belong to the same workflow.

Networking provides another example.

CIDR Calculator

│

├── IP Range Calculator

├── VLSM Calculator

└── MAC Generator

This led me to think about tools as nodes in a graph.

JSON Formatter

/ \

/ \

JSON Schema JSON Diff

\ /

\ /

JSON → CSV

The relationship between applications can be as important as the category they belong to.

Eventually I created workflow-oriented collections, including a "web developer toolkit" (https://navorika.com/toolkits/web-developer-tools), rather than relying exclusively on broad category pages.

This has benefits beyond navigation.

It helps answer the question:

«What is the user likely to need next?»

That's a much more useful question than:

«What other pages can I link here?»

8. Programmatic Pages Need Guardrails

When working with many routes, automation becomes attractive.

A registry can generate:

routes

metadata

sitemaps

breadcrumbs

category pages

related tools

structured data

That's useful.

But automation also makes it extremely easy to create low-quality pages at scale.

Suppose you have 100 tools and automatically generate 100 descriptions like:

Use our X calculator to calculate X quickly and easily.

Technically, you now have 100 pages.

Practically, you have created almost no useful information.

I found it more useful to think of each tool page as answering several questions:

What does this tool do?

How does it work?

What assumptions does it make?

How should I use it?

What does the result mean?

What are its limitations?

What should I use next?

A calculator result without context can be misleading.

This is especially important for financial, health, construction and technical calculations.

9. Build-Time Validation Becomes Essential

Humans are bad at manually maintaining large registries.

Eventually you will:

- add a registry entry without a route

- create a route without registering it

- reference a nonexistent related tool

- duplicate a slug

- forget metadata

- break a category relationship

Instead of relying entirely on code review, I started treating architecture rules as things that could be tested.

Conceptually:

for (const tool of registry) {

assert(routeExists(tool.slug));

assert(validCategory(tool.category));

assert(uniqueSlug(tool.slug));

}

You can go further:

assert(allRoutesAreRegistered());

assert(allRelatedToolsExist());

assert(allCategoriesAreValid());

assert(noDuplicateSlugs());

Then the deployment pipeline becomes something like:

npm run typecheck

npm run validate:architecture

npm run lint

npm run build

This changes architectural conventions from documentation into executable rules.

That's incredibly useful.

Documentation says:

«Please remember to register every tool.»

Validation says:

ERROR: Route exists but registry entry is missing.

I prefer the second.

10. Static Generation Has Been a Good Fit

Many online utilities don't need server rendering for every request.

The application shell, explanation, metadata and UI can often be generated ahead of time.

Then interactive calculations happen in the browser.

Conceptually:

BUILD TIME

↓

Generate tool pages

↓

Static HTML/CSS/JS

↓

Serve page

↓

Browser executes interactive tool

For a platform containing many small utilities, this is an attractive model.

The server primarily delivers the application.

The browser handles much of the interaction.

Of course, some tools genuinely need external data.

Exchange rates are an obvious example.

Current pricing data is another.

The architectural rule shouldn't be:

«Everything must be local.»

It should be:

«Don't introduce server processing unless the functionality requires it.»

11. Reusable UI Is Necessary, but Reusable Logic Is More Important

Component reuse is obvious in React.

You create reusable elements such as:

ToolHeader

InputField

ResultCard

FAQ

RelatedTools

Breadcrumb

But the more important reuse is often behavioral.

For example:

function parsePositiveNumber(value: string) {

const number = Number(value);

if (!Number.isFinite(number) || number <= 0) {

return null;

}

return number;

}

Centralizing common behavior prevents slightly different validation rules from appearing everywhere.

The same applies to:

- number formatting

- percentage parsing

- unit conversions

- file-size validation

- error states

- clipboard behavior

- download helpers

- metadata generation

Consistency becomes more valuable as the application grows.

12. Don't Force Everything Into One Mega-Component

The opposite problem also exists.

Once developers discover reusable components, it's tempting to build:

<UniversalCalculator

formula="..."

inputs={[...]}

output="..."

/>

and force every calculator through it.

That works until the tools become meaningfully different.

A mortgage calculator doesn't behave like a Base64 encoder.

A subnet calculator doesn't behave like an image cropper.

A PDF merger doesn't behave like a construction-material estimator.

Reuse infrastructure.

Reuse patterns.

Reuse validation.

But allow individual tools to own their domain-specific behavior.

I've found that balance much easier to maintain.

13. URLs Become Infrastructure

When you have only a few pages, changing a URL seems harmless.

At scale, URLs become part of the architecture.

Other pages reference them.

Search engines discover them.

Users bookmark them.

External websites may link to them.

A slug such as:

/tools/cidr-subnet-calculator

is no longer merely a filename.

It's a public interface.

This means changing slugs casually becomes similar to changing an API contract.

Stable URLs are worth protecting.

14. Tool Count Is a Bad Success Metric

When I began scaling the project, the number of tools naturally felt important.

50 tools.

100 tools.

150 tools.

But the number itself becomes increasingly meaningless.

I'd rather have:

100 dependable tools

than:

500 pages containing weak implementations

A better set of engineering questions is:

Does the calculation work?

Are inputs validated?

Are limitations explained?

Does it work on mobile?

Is sensitive data unnecessarily transmitted?

Can users understand the result?

Does the related workflow make sense?

Those are harder metrics.

They're also much more useful.

15. What I'd Do Differently If I Started Again

If I were starting the project today, I would establish the registry architecture almost immediately.

My order would probably be:

1. Define the tool schema

2. Define categories

3. Build reusable page primitives

4. Create shared validation helpers

5. Establish URL conventions

6. Add architecture validation

7. Build 10 excellent tools

8. Observe usage

9. Create workflow relationships

10. Scale gradually

Instead, like many side projects, some of the architecture emerged only after the application became complicated enough to require it.

That's not necessarily bad.

Premature architecture can be just as harmful as insufficient architecture.

But once repeated patterns become obvious, formalizing them pays off quickly.

Final Thoughts

Building a large collection of small browser applications has changed how I think about web tools.

The calculation itself is often the easiest part.

The harder problems are:

- architecture

- validation

- privacy

- discoverability

- consistency

- maintainability

- explaining limitations

- deciding when not to ship something

Next.js and modern browser APIs make it surprisingly practical to build useful applications where much of the actual work happens on the user's device.

But scaling from a handful of utilities to hundreds requires treating the project as a system rather than a folder full of pages.

That's what I'm currently experimenting with while building "Navorika" (https://navorika.com/).

And the biggest lesson so far is probably the simplest:

Don't optimize for how many tools you can publish. Optimize for how many problems you can solve correctly.