DEV Community

Richify
Richify

Posted on

How I Built a Decision-Making Assessment for RichifyNow

How I Built a Decision-Making Assessment for RichifyNow

Most calculators start with a simple formula:

Input → calculation → result.

But some problems aren't about calculating a single number.

They're about helping someone understand where they are, what needs attention, and what they should do next.

That was the idea behind the assessment tools created for RichifyNow, a platform focused on wealth building, online business, SaaS tools, business growth, and risk management.

Instead of creating another generic calculator, the goal was to build an assessment that could turn a user's answers into a useful score and actionable recommendations.

The problem

A user might ask:

Is my business model strong enough?
How prepared am I financially?
What areas of my business need attention?
How much risk am I taking?
What should I prioritize next?

A long article can explain these concepts, but an interactive assessment creates a more personalized experience.

The basic flow became:

User answers questions

Validate responses

Assign scores

Calculate category totals

Calculate overall score

Classify the result

Show recommendations

  1. Start with the questions

The first step wasn't writing JavaScript.

It was defining what the assessment actually needed to measure.

For example, imagine a business assessment with five categories:

const categories = {
revenue: 20,
customers: 20,
operations: 20,
marketing: 20,
risk: 20
};

Each category receives a maximum score.

The important part is that the questions should measure something meaningful rather than simply increasing the number of questions.

  1. Convert answers into scores

Each answer can be assigned a numerical value.

For example:

const answerScores = {
weak: 1,
developing: 2,
good: 3,
strong: 4,
excellent: 5
};

When the user selects an answer, the application stores its corresponding score.

const score = answerScores[selectedAnswer];

This makes the assessment logic easier to maintain because the scoring system is separated from the interface.

  1. Calculate the result

Once all questions have been answered, the application adds the scores.

const totalScore = scores.reduce(
(total, score) => total + score,
0
);

We can then convert the result into a percentage:

const percentage =
(totalScore / maximumScore) * 100;

Now we have a standardized result that can be interpreted regardless of the number of questions.

  1. Turn a number into an assessment

A score by itself isn't particularly useful.

For example:

72%

doesn't tell the user much.

So the next layer is classification:

function getLevel(score) {
if (score >= 80) return "Strong";
if (score >= 60) return "Developing";
if (score >= 40) return "Needs Attention";

return "High Priority";
}

Now the application can transform the numerical result into something understandable.

Score: 72%

Assessment:
Developing

Focus:
Improve customer acquisition and operational consistency.

This is where an assessment becomes more useful than a basic calculator.

  1. Show category-level results

The overall score isn't always the most important metric.

Suppose a user receives:

Revenue 85%
Customers 48%
Operations 76%
Marketing 42%
Risk 81%

The overall score might look reasonable.

But the category scores reveal something much more useful:

Marketing and customer acquisition are the biggest weaknesses.

This allows the application to generate more targeted recommendations.

const recommendations = [];

if (marketingScore < 60) {
recommendations.push(
"Review your customer acquisition strategy."
);
}

if (operationsScore < 60) {
recommendations.push(
"Document and improve your core processes."
);
}

  1. Validation matters

One of the easiest mistakes when building an assessment is assuming users will always provide valid input.

They won't.

The application should check:

Required questions
Valid numerical ranges
Missing answers
Invalid values
Duplicate or unexpected input

For example:

if (!selectedAnswer) {
showError("Please answer this question.");
return;
}

Validation prevents misleading results and makes the assessment feel much more reliable.

  1. Keep the calculation logic separate

One design decision that makes these tools easier to maintain is separating the UI from the assessment engine.

Instead of putting everything inside button click handlers:

button.onclick = function () {
// dozens of lines of scoring logic...
};

I prefer small functions:

function calculateScore(answers) {
// scoring logic
}

function getLevel(score) {
// classification logic
}

function getRecommendations(results) {
// recommendation logic
}

function renderResults(results) {
// UI logic
}

This makes the application easier to test and modify.

If the scoring model changes later, the interface doesn't need to be completely rewritten.

  1. The assessment is really a decision-support system

This was the biggest lesson from the project.

The interesting part isn't the arithmetic.

The arithmetic is easy.

The difficult part is deciding:

What should be measured?

How should each answer be weighted?

What does the final score actually mean?

What action should the user take after seeing the result?

That's why the assessment structure is just as important as the code.

RichifyNow takes a similar framework-driven approach across its resources, aiming to turn complex topics into practical frameworks, checklists, comparisons, and action plans.

What I would improve next

If I continued developing the assessment, I'd consider adding:

Saved assessment results
Progress tracking
More detailed recommendations
Comparison against previous assessments
Personalized action plans
Exportable reports
Better accessibility
Automated testing for scoring rules

I'd also test the scoring model with real users.

A technically correct scoring formula can still produce a poor assessment if the questions or weighting don't reflect reality.

Final thoughts

Building a calculator is usually straightforward.

Building an assessment that helps someone make a better decision is a different problem.

The technical architecture can remain relatively simple:

Questions

Validation

Scoring engine

Category analysis

Overall assessment

Recommendations

But the real value comes from the layer above the code: good questions, sensible scoring, clear interpretation, and useful next steps.

Top comments (0)