DEV Community

Cover image for Building Stackly: Lessons from a Bilingual Digital Tools Website
ahmed negm
ahmed negm

Posted on Edited on AI-assisted

Building Stackly: Lessons from a Bilingual Digital Tools Website

Hi DEV! I’m Ahmed, and I’m building Stackly, a bilingual Arabic-English workspace for everyday digital tools.

The project brings together utilities such as percentage calculators, QR code tools, text utilities, and color palette tools.

This is an ongoing project, and I wanted to share a few practical lessons from building and testing it.

1. Language support is more than translation

Supporting Arabic and English involves more than changing labels.

Switching between right-to-left and left-to-right text can affect navigation, input alignment, and the way numbers appear in results.

One challenge has been keeping navigation controls in predictable positions while preserving the correct reading direction for each language.

2. Correct calculations still need clear presentation

When testing a percentage calculator, I found that checking the result alone was not enough.

For example, with a base value of 80 and a percentage of 25, the expected results are:

  • 25% of 80 = 20
  • 80 increased by 25% = 100
  • 80 decreased by 25% = 60

Even when the arithmetic is correct, mixed text directions can make the output difficult to read. Input labels, number formatting, and result layout all need testing.

3. Tool pages should behave like normal web pages

I’ve been working on giving tools their own URLs and making their links behave as visitors expect.

That means considering more than whether a click opens the tool:

  • Can visitors copy or share its URL?
  • Can they open it in another tab?
  • Does the browser’s Back button behave sensibly?
  • Does the page open without unexpected scrolling or distracting movement?

Mobile testing has been particularly useful for spotting these issues.

4. A successful build is not a successful deployment

Another lesson has been to test the deployed website, not just the local build.

The HTML file and its JavaScript assets need to match. Files also need to be uploaded to the correct directory.

During troubleshooting, a missing closing script tag was found in the HTML. It was a reminder that a small markup error can interfere with loading the application.

I’ve also added defensive checks and an error boundary to the admin interface so that some rendering failures can show a useful message instead of only a blank screen.

5. Analytics need clear definitions

I’ve started adding an admin dashboard for page views, visits, recorded tool usage, and service-link clicks.

These measurements describe different things:

  • Opening a tool is not the same as running it.
  • A recorded run does not necessarily prove that the output was correct.
  • A service-link click is not a confirmed sale.
  • An account assigned to a plan is not necessarily an active paid subscription.

Keeping those distinctions visible is important when interpreting reports.

What I’m still improving

Stackly is still evolving. My current priorities include:

  • More consistent Arabic-English presentation.
  • Clearer tool inputs and results.
  • Reliable mobile navigation.
  • Better testing of individual tools.
  • More useful admin reporting.

Some tools use local browser processing or predefined logic. Not every tool is powered by a live AI model, and I do not want the interface to imply otherwise.

Try Stackly

Explore Stackly's digital tools

If you try it, I’d appreciate specific feedback:

  • Which tool did you open?
  • Were its inputs and results clear?
  • Did navigation work as expected on your device?
  • Did you notice any Arabic-English layout issues?

Thanks for reading. I’m sharing this as a work in progress, and practical feedback is welcome.

Disclosure: I’m the person building Stackly. Some service listings on the site may contain affiliate links.

Top comments (0)