From an idea to a growing collection of practical web applications. A look at the development process, technical decisions, challenges and lessons behind AfriWidget.
Building software is interesting. Building software that people can actually use to solve everyday problems is even more interesting.
When I started working on AfriWidget, I wasn't trying to create another website filled with random online calculators. I wanted to build something more useful: a collection of practical digital tools that could make everyday tasks easier, particularly for people who often struggle to find tools designed around their actual needs.
What began as an idea gradually developed into a growing platform containing more than 100 tools and pages across several categories.
The interesting part is how it was built.
AfriWidget was developed using familiar web technologies: HTML, CSS and JavaScript. There was no need to begin with a complicated technology stack or introduce a large collection of frameworks.
Instead, the focus was on building individual tools, making them functional, improving their usability and gradually developing a platform around them.
In this article, I'll explain the thinking behind AfriWidget, the development approach, the technologies involved, some of the engineering challenges and the lessons I learned while building it.
This isn't a claim that everything was perfect. Like most real-world software projects, AfriWidget has required continuous improvements, corrections and difficult decisions.
That's precisely what makes the development process worth discussing.
- The Idea: Building Tools That Solve Actual Problems
Every useful software product starts with a problem worth solving.
People regularly need to calculate percentages, understand academic results, manage information, estimate expenses and complete other everyday tasks.
Although many websites provide calculators and similar utilities, finding a tool that properly addresses a particular country's educational system, grading structure or specific requirements can sometimes be difficult.
Consider academic calculations.
A student might need to understand their examination aggregate, calculate a weighted assessment score or estimate whether their results meet a particular admission requirement.
A generic calculator cannot necessarily handle these situations correctly.
The calculation might depend on a specific grading structure, subject combination, weighting system or institutional requirement.
This presented an interesting development opportunity.
Instead of creating only general-purpose calculators, why not build tools that address specific problems?
That became one of the ideas behind AfriWidget.
The objective was to create practical tools that people could access directly through a browser without having to install an application.
The platform would focus on usability, accessibility and solving clearly defined problems.
The guiding idea became:
Built in Ghana. Made for the World.
AfriWidget isn't intended exclusively for African users. Its educational tools include region-specific functionality where necessary, while its broader collection addresses problems that people around the world experience.
- Choosing the Technology Stack
One of my earliest development decisions was choosing the technologies that would power the platform.
I wanted a stack that would allow me to build quickly, maintain control over the implementation and avoid unnecessary complexity.
The core technologies were:
- HTML
- CSS
- JavaScript
These three technologies provide everything needed to build interactive browser-based applications.
HTML: Structuring the tools
HTML provides the structure of each application.
For a calculator, this includes:
- Input fields.
- Labels.
- Buttons.
- Result sections.
- Instructions.
- Validation messages.
For example, a simple percentage calculator might require two numerical inputs and a button to calculate the result.
HTML defines these elements and their relationships.
I also wanted the pages to use meaningful semantic elements rather than relying entirely on generic containers.
This helps make the content easier to understand for browsers, assistive technologies and search engines.
CSS: Designing the experience
CSS controls how the applications look and behave visually.
For AfriWidget, the design direction uses a relatively simple visual identity built around black, yellow and white.
The intention was to avoid unnecessary visual complexity.
A calculator should make its purpose obvious.
Users should understand where to enter information, how to perform a calculation and where to find the result.
CSS also handles responsiveness.
This is particularly important because many people access online tools using smartphones rather than desktop computers.
The interface needs to remain usable on smaller screens without requiring users to zoom in or navigate unnecessarily complicated layouts.
JavaScript: Making everything functional
JavaScript handles the actual behaviour of the tools.
It processes inputs, performs calculations, validates information and updates the interface.
For example, consider a weighted academic score calculator.
The calculation might involve several assessment components, each contributing a different percentage to the final result.
JavaScript can receive the scores, apply the appropriate weights and calculate the final value.
A simplified example:
function calculateWeightedScore(
assignment,
test,
examination
) {
const result =
(assignment * 0.20) +
(test * 0.30) +
(examination * 0.50);
return result;
}
console.log(
calculateWeightedScore(80, 70, 60)
);
The output is:
67
This is a small example of the calculation logic.
A real application also needs input validation, appropriate score limits, error handling and clear result presentation.
The important architectural decision was that the core functionality could be implemented directly in the browser without requiring a backend for every calculation.
- Building Individual Tools Instead of One Complicated Application
One of the most important decisions was treating the tools as individual applications within a larger platform.
This approach makes it possible to develop different tools around their specific requirements.
An academic calculator doesn't necessarily need the same input structure as a financial calculator.
A productivity tool may require a completely different interaction model.
Trying to force every tool into one complicated interface would introduce unnecessary limitations.
Instead, each tool can have its own:
- Interface.
- Calculation logic.
- Validation rules.
- Instructions.
- Results presentation.
- Supporting content.
This provides flexibility.
It also means that improvements can be made to individual tools without automatically changing the behaviour of unrelated applications.
However, this approach introduces another challenge: consistency.
When a platform contains dozens or hundreds of individual tools, maintaining a consistent user experience becomes increasingly important.
Users shouldn't feel like they are visiting completely unrelated websites whenever they move between tools.
This is where shared design principles, navigation patterns and common functionality become useful.
- Developing the Educational Tools
Education became one of the central areas of AfriWidget.
This wasn't simply about creating generic calculators.
The challenge was understanding that different educational systems use different rules.
A calculation that works for one country might be completely incorrect for another.
WASSCE Aggregate Calculator
The WASSCE calculator was designed around the grading requirements relevant to the examination system.
The implementation needs to account for subject grades, the best-six calculation and relevant core subjects.
This introduces several considerations.
For example:
- Which subjects are mandatory?
- Which subjects should contribute to the aggregate?
- How should grades be converted into numerical values?
- How should missing or invalid selections be handled?
- How should the result be explained?
The calculation logic must reflect the applicable grading rules.
A visually attractive calculator is not useful if its underlying academic calculation is wrong.
JAMB UTME Calculator
The JAMB calculator requires a different calculation structure.
Its inputs and scoring logic are not interchangeable with those of WASSCE.
This illustrates an important software development principle:
Similar-looking tools can have completely different business logic.
The interface might share design patterns, but the underlying implementation must respect the requirements of the specific examination system.
South African Educational Tools
Another interesting area was developing tools for South African students.
This included tools related to APS calculations and TVET assessment systems.
The ICASS calculator was particularly interesting because it deals with continuous assessment components and their contribution to academic performance.
For example, an assessment might contain different components with different weightings.
The application must interpret those weights correctly before producing a result.
Developing these tools reinforced an important lesson: understanding the domain is just as important as understanding JavaScript.
You cannot reliably implement a specialised educational calculator simply by guessing the formula.
You need to understand the actual requirements, verify the calculation and communicate any relevant limitations to users.
- Making the Platform Useful Beyond Calculators
As the project developed, it became clear that simply providing calculations was not enough.
People often need help understanding their results and deciding what to do next.
This led to the development of additional functionality.
Find My Weaknesses
One of the educational features focuses on helping students identify areas where they need improvement.
The idea is to move beyond simply displaying a numerical result.
A student might know their examination score but still struggle to understand which concepts require more attention.
A weakness-identification experience can help direct attention towards specific topics and provide opportunities for practice.
This introduces additional development requirements:
- Question organization.
- Difficulty levels.
- Answer validation.
- Performance tracking.
- Feedback.
- Progress monitoring.
It also requires careful attention to the user experience.
Students should not have to navigate a long, intimidating introduction before starting a useful activity.
The experience should make it easy to begin.
Continue Where You Left Off
Another useful idea is reducing the amount of work users need to repeat.
For example, someone using a calculator might leave the page and return later.
A continuation feature can help users find previously used tools and, where supported, resume their work.
This kind of functionality requires decisions about data persistence and privacy.
If information is stored locally in the browser, users should have a clear way to remove it.
Favourites
A growing platform can make finding tools difficult.
A favourites feature gives users a way to keep track of tools they use regularly.
Rather than searching through multiple categories every time, they can access their preferred tools more easily.
This is a relatively small feature, but it addresses a practical usability problem.
Academic Progress Tracking
Another direction is helping students understand their progress over time.
A single examination result provides only a snapshot.
Tracking multiple results can reveal whether performance is improving, declining or remaining relatively consistent.
A useful progress tracker should present information clearly rather than overwhelming users with unnecessary statistics.
These features represent a broader shift in the project's thinking.
The objective is not simply to provide more calculators.
It is to create more useful experiences around the problems those calculators address.
- Why I Avoided an Unnecessarily Complicated Framework Stack
Modern web development offers many frameworks and development environments.
React, Vue, Angular, Next.js and other technologies provide powerful ways to build applications.
They are valuable tools, and there are situations where using them makes perfect sense.
However, not every project needs them.
For AfriWidget, the initial priority was building lightweight browser-based tools.
HTML, CSS and JavaScript were sufficient for implementing the core functionality.
This offered several advantages.
Less unnecessary complexity
There was no requirement to introduce a large framework simply to calculate numbers, validate inputs and display results.
Direct control
The implementation remained close to the underlying browser technologies.
Lightweight delivery
Individual tools could be designed without requiring an unnecessarily large application runtime.
Accessibility of development
The core technologies are widely understood and have extensive documentation.
There are trade-offs, of course.
As the number of tools increases, maintaining consistency and avoiding duplicated code becomes more challenging.
A collection of individually developed pages can gradually become difficult to manage if there are no clear conventions.
This is an area where good organization, shared components where appropriate and consistent development practices become increasingly important.
The lesson isn't that frameworks are bad.
It's that technology choices should follow the needs of the project rather than fashion.
- The Importance of Input Validation and Calculation Accuracy
One of the most important engineering lessons from building calculators is that accepting input is not the same as handling input correctly.
Consider a calculator that expects a score between zero and one hundred.
What happens if someone enters:
- A negative number?
- 150?
- An empty field?
- Text instead of a number?
- A decimal value?
- An unusually large number?
Without proper validation, the application might produce misleading results or behave unexpectedly.
A simple JavaScript validation example looks like this:
function validateScore(value) {
const score = Number(value);
if (value === "" || !Number.isFinite(score)) {
return {
valid: false,
message: "Please enter a valid number."
};
}
if (score < 0 || score > 100) {
return {
valid: false,
message: "Score must be between 0 and 100."
};
}
return {
valid: true,
value: score
};
}
This function checks whether the input is a valid numerical value within the specified range.
However, validation rules must be based on the actual requirements of each tool.
Not every calculator should have the same limits.
For example, a percentage calculator might accept values beyond 100 depending on its purpose, while a particular examination score field may have a strict maximum.
Another important consideration is independent verification.
For mathematical tools, I consider it essential to compare application results with manually calculated examples.
A tool should not be considered complete simply because its button works.
Its results must also be correct.
- SEO: Making Useful Tools Discoverable
Building a useful application is only one part of creating a successful web platform.
People also need to find it.
Search engine optimization became an important part of developing AfriWidget.
The challenge was that each tool addressed a different search intent.
Someone searching for an ICASS calculator has a different requirement from someone searching for a WASSCE aggregate calculator.
A single generic homepage cannot fully address every one of those needs.
This made individual tool pages important.
Each page needed to communicate:
- What the tool does.
- Who might benefit from it.
- What information users need.
- How the calculation works.
- How to interpret the result.
- What limitations apply.
Writing useful supporting content
A calculator without sufficient explanation can leave users confused.
For example, a student might receive an aggregate but not understand how it was calculated.
Supporting content can explain the grading system, calculation method and relevant considerations.
This provides value beyond the calculator itself.
It also creates opportunities for search engines to understand the purpose of individual pages.
However, publishing large quantities of repetitive content is not a sustainable SEO strategy.
A page should exist because it serves a meaningful purpose.
Adding paragraphs simply to increase word count does not automatically make a tool more useful.
Technical SEO
Technical considerations also matter.
These include:
- Descriptive page titles.
- Useful meta descriptions.
- Logical heading structures.
- Canonical URLs.
- Internal links.
- Mobile usability.
- Search engine accessibility.
- Structured data where appropriate.
Structured data can help search engines understand certain types of content, but it should accurately describe what users can actually see on the page.
SEO should support the product rather than dictate misleading content.
- Performance and the Importance of Lightweight Tools
A website does not become successful simply because it contains many features.
If users have to wait too long for a calculator to load, they may leave before using it.
Performance was therefore an important consideration.
Using browser-native technologies provides opportunities to keep individual tools relatively lightweight.
However, writing vanilla JavaScript does not automatically guarantee good performance.
Poorly optimized JavaScript can still create slow interfaces.
Large images, unnecessary scripts, excessive DOM updates and inefficient event handling can affect the user experience.
Some practical considerations include:
Keep dependencies under control.
Every external library should serve a meaningful purpose.
Optimize images.
Use appropriate image dimensions and modern formats where suitable.
Avoid unnecessary JavaScript execution.
Only perform work when it is needed.
Keep interfaces responsive.
A calculator should not become difficult to use when the screen becomes smaller.
Test on real devices.
Desktop testing alone does not reveal every mobile performance problem.
A website should be evaluated under realistic conditions, including slower connections and less powerful devices.
- Browser Storage and User Privacy
As AfriWidget introduced more interactive features, browser storage became increasingly relevant.
Some functionality is more convenient when information can be retained locally.
For example:
- Favourite tools.
- Previously used tools.
- Saved calculation information.
- Academic progress.
- User preferences.
JavaScript provides browser storage mechanisms such as localStorage.
A simple example:
const preferences = {
theme: "dark",
language: "en"
};
localStorage.setItem(
"userPreferences",
JSON.stringify(preferences)
);
The information can later be retrieved:
const savedPreferences = JSON.parse(
localStorage.getItem("userPreferences") || "{}"
);
console.log(savedPreferences.theme);
This allows an application to preserve certain preferences without requiring a server-side database.
However, local storage introduces responsibilities.
Developers should consider:
- What information is being stored?
- Why does the application need it?
- How long should it remain?
- Can users delete it?
- Is sensitive information being stored unnecessarily?
- What happens when stored data becomes incompatible with a newer version?
Local storage should not be treated as a secure place for passwords, authentication secrets or highly sensitive personal information.
Privacy also needs to be explained clearly.
If an application stores user information locally, users should know what is stored and how to remove it.
Convenience should not come at the expense of transparency.
- Challenges That Come With Scaling a Collection of Tools
One of the interesting things about AfriWidget is how quickly a small collection of tools can grow into a much larger platform.
Developing five calculators is one thing.
Maintaining more than one hundred tools and pages introduces an entirely different set of challenges.
Maintaining consistency
Different tools can gradually develop different design patterns.
Buttons might have inconsistent sizes.
Input fields might behave differently.
Navigation might become difficult to predict.
This creates a fragmented experience.
The solution is to establish shared design principles and review individual tools regularly.
Avoiding duplicated logic
When several tools use similar functionality, developers may end up implementing the same logic repeatedly.
For example, multiple calculators might need numerical validation.
Without reusable patterns, maintaining those implementations can become unnecessarily difficult.
A useful approach is identifying functionality that can be shared without forcing unrelated tools into the same implementation.
Managing changes safely
Updating a platform with many independent pages requires care.
A change that improves one tool should not unexpectedly break another.
This makes regression testing important.
After making changes, developers should check both the modified functionality and important existing behaviour.
Knowing when to remove features
There is a common assumption that adding more features always improves a product.
It doesn't.
Sometimes a feature introduces maintenance costs without providing enough value.
Sometimes an entire category needs reconsideration because the available tools do not meet the quality standards of the platform.
Removing unnecessary functionality can be just as important as introducing new functionality.
A healthy product should evolve based on usefulness, reliability and actual user needs.
- Hosting and Deployment
A web application needs to be accessible beyond the developer's local environment.
For a static-first platform like AfriWidget, static hosting is a practical approach.
Services such as Cloudflare Pages can host static HTML, CSS and JavaScript projects and distribute content through a global network.
The basic deployment process involves:
- Preparing the project files.
- Organizing the pages and assets.
- Connecting the project to a supported deployment workflow.
- Configuring the domain.
- Deploying the website.
- Testing the published pages.
A major advantage of static hosting is that individual browser-based tools do not necessarily need a continuously running application server.
The browser performs the calculations.
The hosting platform delivers the files.
This can reduce infrastructure complexity for tools that do not require server-side processing.
However, not every future feature will necessarily fit this architecture.
Features involving authentication, protected information, server-side AI processing or external integrations may require additional infrastructure.
Choosing a static-first approach does not mean refusing to use backend services when they become necessary.
It means avoiding infrastructure that the current problem does not require.
- Learning From Real Usage Instead of Guessing
Building a website and understanding how people use it are two different things.
Analytics can help developers discover what is happening after deployment.
For example, a developer might assume that a newly introduced feature is popular because it took considerable time to build.
Actual usage might tell a different story.
Some tools may attract substantial search traffic.
Others may receive very little attention.
Some visitors may interact with a calculator and leave immediately because they obtained the answer they needed.
That is not necessarily a negative experience.
A short session can still represent a successful interaction.
Analytics should therefore be interpreted in context.
Useful measurements can include:
- Page views.
- Active users.
- Tool interactions.
- Search impressions.
- Search clicks.
- Search rankings.
- Conversion events.
- Errors and failed interactions.
One important lesson is that traffic alone doesn't establish product quality.
A tool that attracts thousands of visitors but regularly produces incorrect results is not a successful product.
Likewise, a useful tool with limited visibility may need better discoverability rather than a complete redesign.
The goal is to combine user feedback, technical testing and analytics when deciding what to improve.
- What I Would Do Differently If I Started Again
Looking back at the development process, there are several areas I would approach more deliberately.
Establish stronger shared conventions earlier
When building many independent tools, consistency becomes increasingly important.
I would establish clearer conventions for file organization, naming, shared functionality and design patterns from the beginning.
Build testing into the development process
Testing should not become an activity reserved for the end of development.
Each tool should have a defined set of expected inputs, outputs and edge cases.
This is particularly important for academic and financial calculations.
Prioritize quality over quantity
It is tempting to measure progress by the number of tools published.
However, a smaller collection of accurate, well-maintained tools can provide more value than a much larger collection of unfinished or poorly explained applications.
Think about privacy before introducing storage
Features such as favourites, saved progress and continuation functionality should be designed with privacy in mind.
Users should understand what information is retained and how they can remove it.
Treat content as part of the product
Instructions, explanations and supporting articles are not merely SEO additions.
They help users understand how a tool works and whether its results are relevant to their situation.
This is particularly important when dealing with educational calculations.
- What Comes Next for AfriWidget?
AfriWidget is an evolving project.
The intention is to continue improving the quality and usefulness of its existing tools rather than simply increasing the number of published pages.
Some important areas of continued development include:
Better educational experiences
Making academic tools more useful through clearer explanations, performance tracking and opportunities for students to identify areas that need improvement.
Improved user experience
Reducing unnecessary steps, improving mobile usability and making important actions easier to understand.
More reliable calculations
Reviewing formulas, handling edge cases and providing transparent explanations of calculation methods.
Better organization
Making it easier for visitors to discover relevant tools without navigating unnecessarily complicated categories.
Thoughtful new functionality
Introducing features when they solve genuine problems rather than adding them simply because they are technically possible.
The long-term objective is to make AfriWidget a useful collection of digital tools for people in different parts of the world.
- Final Thoughts: Build Something Useful, Then Keep Improving It
AfriWidget has taught me that building a software product is not just about writing code.
It involves identifying problems, understanding users, making technical decisions, testing assumptions and accepting that the first implementation will not always be the best one.
HTML, CSS and JavaScript made it possible to build a growing collection of browser-based tools without introducing unnecessary complexity at the beginning.
But the technologies themselves were never the main achievement.
The more important part was identifying problems worth solving and continuously improving the solutions.
There is a lesson here for developers, particularly those working independently.
You don't need to begin with an enormous application.
You don't need to use every popular framework.
You don't need a large team before you can create something useful.
Start with a problem you understand.
Build a small solution.
Test it properly.
Listen to how people use it.
Improve what doesn't work.
And don't be afraid to remove something that no longer serves a purpose.
A project becomes more valuable not simply because it grows, but because it becomes better at doing what it was created to do.
That is the principle I want AfriWidget to continue following.
Explore the Project
AfriWidget is an independent project founded by Obed Avorlenu.
It is built in Ghana and developed with the intention of making practical digital tools accessible to people around the world.
The platform includes tools covering education, finance, productivity, business and other everyday needs.
You can explore the project here:
"AfriWidget — Built in Ghana. Made for the World." (https://afriwidget.com)
I'm also interested in hearing from other developers who have built independent products using HTML, CSS and JavaScript.
Discussion questions:
- What would you choose for a project like this: vanilla JavaScript or a framework?
- How do you maintain consistency when managing dozens or hundreds of independent tools?
- What is one technical decision you would make differently if you started your first major project again?
I'd be particularly interested in hearing from developers who have experience building and maintaining large collections of small web applications.
Top comments (0)