I’m Building Axevora: What I Learned While Turning 120+ Web Tools Into One Website
Live project: https://axevora.com/
I've been working on a project called Axevora, and I wanted to share it here because it has turned into something much bigger than the original idea.
The basic idea sounded simple:
Build useful web tools that people can open in their browser and use immediately.
But once the number of tools started growing, I realized that building 5 tools and building 120+ tools are completely different problems.
At some point, you're no longer just building individual utilities.
You're building a small ecosystem.
And that's where things started getting interesting.
What is Axevora?
Axevora is a web platform that brings together:
- Free online utilities
- Productivity tools
- Developer tools
- PDF and document tools
- Image tools
- Text and code utilities
- Calculators
- AI utilities
- Browser games
- Community discussions
- Shopping and deals
- Guides and articles
The idea isn't to create another website where everything is thrown into one giant menu.
The challenge is making a large number of small products still feel like one coherent platform.
You can explore it here:
The original problem
There are thousands of small web tools available online.
Need to convert an image?
Search for a tool.
Need to format JSON?
Search again.
Need a QR code?
Another website.
Need to compress a PDF?
Another tab.
Need a calculator?
Another search.
After a while, your browser starts looking like a collection of bookmarks you never organized.
I wanted to experiment with a different approach:
What if these small utilities lived under one ecosystem?
Instead of creating a separate brand and interface for every tiny problem, Axevora gives them a common home.
But building 120+ tools isn't just about creating 120 pages
This was probably the biggest lesson for me.
When you have one tool, you can get away with a lot.
You can hardcode things.
You can make assumptions.
You can manually fix small UI problems.
You can tolerate inconsistent naming.
You can even tolerate a little technical debt.
But when you have dozens of tools, those shortcuts start multiplying.
A small inconsistency repeated across 100+ pages becomes a platform problem.
For example:
- Different button styles
- Different error messages
- Different loading states
- Different mobile behavior
- Different navigation patterns
- Different metadata
- Different URL structures
- Different empty states
Suddenly you're not maintaining one application.
You're maintaining a system.
The interesting part: consistency
One of the things I've been focusing on is making individual tools feel like they belong to the same product.
A user shouldn't have to learn a completely new interface every time they open another utility.
The basic interaction patterns should remain familiar.
Upload.
Process.
Preview.
Download.
Or:
Enter.
Calculate.
Copy.
Reset.
Or:
Paste.
Format.
Validate.
Copy.
These patterns are simple, but keeping them consistent across a large tool ecosystem makes a surprisingly big difference.
Not every tool needs a backend
Another design decision I've been exploring is whether a tool actually needs server-side processing.
For many utilities, it doesn't.
If the browser can safely perform the operation locally, there is little reason to send the user's data somewhere else just to perform a simple transformation.
This is particularly useful for things like:
- Text formatting
- JSON formatting
- Calculations
- Image processing
- Some document operations
- Code utilities
- Generators
- Validation tools
That creates an interesting architecture question:
Which operations should happen in the browser, and which actually need server-side infrastructure?
I don't think there is one universal answer.
It depends on the operation, file size, browser capabilities, security requirements and expected workload.
Privacy becomes a technical design decision
"Privacy-first" sounds like a marketing phrase until you actually have to decide where user data goes.
If a user uploads a file to a tool, there is a fundamental difference between:
Browser → process locally → result
and:
Browser → upload file → server → process → download result
The second architecture may be necessary for certain workloads.
But when it isn't necessary, local processing can be a very useful option.
That's one of the principles I've been trying to apply throughout Axevora:
Don't send data to a server just because you can.
If something can reasonably be handled in the browser, keeping the workflow local can simplify both the user's privacy model and the application's infrastructure.
Then came the SEO problem
Building tools is only half the challenge.
People need to find them.
A useful tool that nobody can discover is basically invisible.
And this is where building a large utility ecosystem gets complicated.
Every tool potentially has:
- Its own URL
- Its own title
- Its own description
- Its own structured content
- Its own internal links
- Its own category
- Its own search intent
Once you have hundreds of URLs, SEO stops being a "write a meta description" problem.
It becomes an information architecture problem.
Categories became important
Instead of treating every tool as an isolated page, I started organizing tools into broader categories.
For example:
PDF & Document Processing
Converters, editors, compression, page operations and related utilities.
Image Tools
Converters, compressors, resizers, analyzers and other image utilities.
Developer Utilities
Formatters, validators, encoders, generators and developer-focused tools.
Calculators
Financial, mathematical and everyday calculators.
AI Tools
AI-assisted creation and productivity utilities.
Games & Arcade
Browser-based games and small interactive experiences.
This makes the platform easier to navigate for humans and also gives search engines a clearer understanding of the relationship between pages.
The homepage isn't supposed to do everything
Another lesson I've learned:
A homepage doesn't need to explain every feature.
Axevora has a lot of things happening:
Tools.
Games.
Community.
Shopping.
Deals.
Blog.
If I tried to put every feature on the homepage equally, it would become a wall of links.
Instead, the homepage needs to answer a simpler question:
What is this website and where should I go next?
Then the category pages, tool pages and community pages can do the deeper work.
That separation makes the architecture easier to understand.
I also wanted a community layer
This was another interesting addition.
Tools solve problems.
But developers, creators and website owners also need somewhere to talk about what they're building.
So Axevora now has a community section with dedicated discussion boards.
One of them is the:
Websites & Blogs Community Board
https://axevora.com/community/boards/websites-blogs
The board is intended for:
- Website launches
- Personal developer blogs
- SaaS projects
- Technical discussions
- Architecture ideas
- Web performance
- Core Web Vitals
- UI/UX feedback
- Accessibility discussions
The goal is to make it possible for people to share what they're building while keeping the discussion useful.
Why I separated community boards
A single "Community" page can become noisy very quickly.
Someone wants to promote a YouTube video.
Someone else wants feedback on a SaaS.
Another developer wants to discuss a serverless architecture.
Someone else wants to share a website.
These aren't necessarily the same conversation.
So separating them into dedicated boards creates clearer contexts.
For example:
Websites & Blogs
for websites, blogs and SaaS projects.
AI & Technology
for AI workflows, developer tools and emerging technology.
YouTube Promotion
for video creators.
Creator Promotion
for creative work and portfolios.
Deals & Offers
for software and technology deals.
That structure is still evolving, but the principle is simple:
Give different types of conversations their own space.
Building a website is also an operations problem
This is something I didn't fully appreciate at the beginning.
When you're building a small project, development is the main activity.
When the project grows, maintenance becomes a major part of development.
You start asking questions like:
- Did this change break another tool?
- Is this page still accessible?
- Did a route change?
- Is the mobile layout still working?
- Are internal links correct?
- Are metadata and canonical URLs correct?
- Are generated pages discoverable?
- Did a deployment affect an unrelated feature?
This is where having a structured architecture matters.
The more pages you have, the more expensive careless changes become.
Small changes can have large consequences
One of the biggest lessons I've learned while working on Axevora is:
Don't fix one problem by creating three others.
For a platform with tools, games, community, shopping, blog pages, analytics and SEO systems, a seemingly small global change can have unexpected consequences.
For example, changing a shared component can affect dozens of tools.
Changing routing can affect search indexing.
Changing metadata generation can affect hundreds of pages.
Changing an API response can affect multiple features.
That's why I've become much more conservative about production changes.
First understand the system.
Then identify the actual root cause.
Then make the smallest change that solves the problem.
Then test.
What I'm still working on
Axevora is very much an ongoing project.
Some areas I'm continuing to improve include:
- Better tool discovery
- Faster page experiences
- Mobile UX
- Internal linking
- Search visibility
- Community features
- Better tool categorization
- More browser-based utilities
- Better documentation
- More useful technical content
The challenge is resisting the temptation to add features just because they're possible.
A bigger website isn't automatically a better website.
The goal is to make the existing ecosystem more useful.
What I would do differently if I started again
Probably one thing above everything else:
I would design the architecture around scale earlier.
When you're building the first few tools, it is tempting to think:
"I'll clean this up later."
Then tool number 10 arrives.
Then 20.
Then 50.
And suddenly "later" becomes a major refactoring project.
If you're building a platform that you expect to grow, it is worth thinking about:
- Shared components
- Routing
- Metadata
- Categories
- Internal links
- Error handling
- Analytics
- Performance
- Mobile layouts
- Deployment
- Testing
before the project becomes huge.
You don't need enterprise architecture on day one.
But you should know which parts you expect to scale.
I'm curious how other developers approach this
This is where I'd really like some feedback from the DEV community.
If you're building a website, SaaS product, developer platform or collection of online tools:
How do you handle growth?
Do you prefer:
- One large application?
- Multiple smaller applications?
- Micro-frontends?
- Static pages + APIs?
- Serverless?
- Traditional backend architecture?
- Mostly client-side processing?
- A hybrid approach?
And when you reach 50, 100 or 500+ pages, what becomes your biggest maintenance problem?
SEO?
Routing?
Performance?
Design consistency?
Testing?
Content?
Infrastructure?
I'd genuinely like to hear what other developers have experienced.
If you're building a website, I'd love to see it
I created the Axevora Websites & Blogs Community Board specifically for this kind of discussion.
You can share:
- Your website
- Your blog
- Your SaaS
- A technical project
- An architecture you're experimenting with
- A redesign
- A performance improvement
- A development milestone
👉 Join the Websites & Blogs board:
https://axevora.com/community/boards/websites-blogs
And if you're curious about the project I'm working on:
🚀 Explore Axevora:
I'm still building, fixing, experimenting and learning.
So if you spot something interesting—or something you think could be improved—I'd genuinely like to hear it.
Top comments (0)