Forem: Dang Quoc Khanh

🏠 Stop guessing construction costs.

Dang Quoc Khanh — Fri, 08 May 2026 02:28:18 +0000

We built VatgiaTop to help homeowners, contractors, and architects quickly check material prices and estimate construction costs in Vietnam.

With VatgiaTop, you can:
• Check updated construction material prices
• Estimate your dream house budget
• Explore house construction cost references
• Save time comparing quotations manually

Building a house is already stressful enough — pricing shouldn’t be.

Would love your feedback, support, and ideas for improving the platform.

👉 VatgiaTop — Checking prices & estimating your dream house costs smarter.

What I Learned After Working with Real Construction Costs in Vietnam (And Why Most People Get It Wrong)

Dang Quoc Khanh — Wed, 06 May 2026 01:30:26 +0000

If you've never built a house in Vietnam, there's one thing you should know upfront:

The biggest mistake isn't design, labor, or even contractors - it's misunderstanding material costs.

After years working in construction and consulting homeowners, I've seen the same issue over and over again:
People start building with a rough budget... And end up overspending by 20-30%.

And honestly? It's not their fault.

The Hidden Problem: "Estimated" Prices Are Often Fiction

Most homeowners rely on:

Old Excel sheets
Rough quotes from contractors
Or "market price" conversations

But here's the reality:

Construction material prices change constantly - and vary by province.

For example, cement, steel, sand, and brick prices are updated monthly or quarterly by provincial Departments of Construction, and they can differ significantly between regions. ([Vt Gi Top][1])

That means:

A price in Ho Chi Minh City isn't a price in Da Nang
A quote from last month may already be outdated

So when you estimate based on "average numbers," you're already starting with inaccurate data.

Real Experience: Where Costs Actually Go Wrong

From real projects I've worked on, cost overruns usually come from:

1. Material price mismatch

You planned with:

Steel: X price
Cement: Y price

But when buying:

Prices increased
Or suppliers quoted higher

Result: Budget breaks immediately.

2. No quantity calculation

Many people don't calculate:

How much steel per m
How many bricks per wall
How much concrete per floor

So they:

Buy too much waste, estimate over the reality
Or buy too little delays + higher cost later, cost change every day but we normaly didn't realize it

3. Contractor opacity

A common issue in Vietnam:

Contractors buy materials without transparency
Homeowners don't see real invoices

This is why experienced builders always insist on:

Clear material price lists
Stage-by-stage payments
Independent verification when possible

(If you skip this, you're basically handing over control of your budget.)

What Actually Works (From Practice)

After dealing with multiple projects, I simplified everything into 3 rules:

Rule #1: Always use real, local price data

Not averages. Not guesses. You need:

Province-specific prices
Updated regularly

Rule #2: Estimate based on area + coefficients

Instead of guessing totals:

Calculate cost per m
Multiply by real material prices
Adjust based on house type (townhouse, villa, etc.)

This is how professionals estimate quickly - and much more accurately.

Rule #3: Break everything into components

A house is not one cost.

It's:

Foundation
Structure
Finishing
Interior

When you break it down:

You see where money goes
You control cost much better

Why I Built This Tool

After seeing the same problems repeatedly, I wanted something simpler:

A place where you can:

Check real construction material prices
Estimate house costs based on actual data
Avoid "guess-based budgeting"

So I built:
https://vatgia.top/

What it does:

Provides construction material prices across 34 provinces in Vietnam
Aggregates data from official sources
Includes tools like:
- House cost estimator
- Material calculator
- Quick price lookup

Instead of guessing, you can base your decisions on real numbers.

A Practical Example

Let's say you're building a 100m house.

Instead of:

"I think it costs around $X..."

You can:

Select your province
Get actual material prices
Estimate cost based on structure + materials
Imagine how you use their house after its done (this is a important way to thinking about how to use it and reduce the gap between thinking and using)

Even with normal variance, the error is usually around 10-20% instead of 30-50% when guessing. ([Vt Gi Top][1])

That difference alone can save you thousands.

Final Thoughts

Building a house is not just about design or aesthetics.

It's a data problem.

If your inputs (material prices, quantities) are wrong:
Your entire budget will be wrong.

But if your inputs are accurate:
Everything becomes predictable.

If you're planning to build (or just curious about construction economics in Vietnam), feel free to explore:

https://vatgia.top/

I built it to solve a real problem I kept seeing in the field -
and hopefully, it saves you from the same mistakes.

Writing (unit) tests action, event in Moleculer with Jest

Dang Quoc Khanh — Wed, 15 Feb 2023 16:22:50 +0000

1. Preface ⛄

Moleculer is a powerful microservice framework for NodeJs. Because of designed by a microservice architect, we have more than one service responsible for its duty. In order to communicate with other nodes, we can configure transporter like TCP, NATS, Redis transporter, MQTT, AMQP, and Kafka,.. or customize them to be suitable for your business.

Beside design feature to interact with other node, we need to writing unitest for each feature, function inside to it. An aspect of it, we also need to write unitest for action call each other. In this post, I will present a few of my ways to write unitest in this case.

Note: Please reading about Broker, Transporter, Action, Events concept before reading this post.

2. Understand about action, event in Moleculer

In the real world, if each of us represents a service so the actions look like the request you need from the other. But we have two cases to request something. First, we request something from others and want the result. Second, we request from others and we do not need or care about their response.
I have two easy-to-understand examples of these concepts:

Bob goes to the market and tells to the cashier, "I want to buy an apple". the cashier checks their stock and sells it to Bob or tells him it's out of stock. Bob will get the response from the cashier. This is the mechanism of actions in moleculer.
Bob's garbage was full so he leave them in the trash can and he doesn't need to know when they take it out or how to process the rubbish. He just leaves it and goes back to his work. This is the mecahnism of events in moleculer framework.

3. How to test action, event

Let's join the main content. Different from testing on the monolithic architecture, each service can be located on a different server and called to another service via the transporter.

In the original document, the example already tests the event called by the action. Based on the moleculer testing document, I have the basic implement test action which calls another action with 3 steps:

Mock service broker.
Create two services (we can load/create/import or create a new service and set test action to this service).

Okay, let's take an overview of the code...

describe("Testing calling actions", () => {
    // Mock service broker
    let broker = new ServiceBroker({ logger: false });

    // set start and stop service 
    beforeAll(() => broker.start());
    afterAll(() => broker.stop());

    // create bob service
    broker.createService({
      name: "bob-service",
      actions: {
        goToMarket(ctx) {
          const buyAppleResponse = ctx.call("cashier-service.sellApple");
          return buyAppleResponse;
        }
      }
    })

    // create cashier service
    broker.createService({
      name: "cashier-service",
      actions: {
        sellApple(ctx) {
          const isAvailableApple = true;
          return isAvailableApple;
        }
      }
    })

    // process test
    describe("Test bob buy apple", () => {
      it("should calling to another action", async () => {
        const viewBobGoToMarket = await broker.call("bob-service.goToMarket");
        console.log(viewBobGoToMarket);
      })
    })
})

Logic:

First I want to mock a service broker to create an individual environment to run our test.
Next, I re-build two services corresponding to Bob and Cashier and also create action for each service.
Process call service via Service Broker to make sure it works.

You can imagine the communication above like this:

When we replace the actions called with the events, we will not have the response because we don't care about the result or whether the call event lose.

Another way to test an action is to get only the action that we need to test and mock all actions, events, calling to the database,.. inside this test action. The solution depends on your style, business logic, or use context.

4. Conclusion

Here is an unitest example when I'm trying to test action with mock action. It's similar when we replace action by event. I think it is simple and hope it easy to understand. I'm new bie in microservice and moleculer framwork, give me an comment if I have any shortcoming.

Follow me and give me your heart if you're interesting ❤️
Thanks for reading 😍

5. Reference

https://moleculer.services/docs/0.14/testing.html

Logging levels

Dang Quoc Khanh — Tue, 14 Feb 2023 15:10:03 +0000

Logging levels?

Log is a piece of information that was shown when the application runs through that code. Its information serves for troubleshooting and monitoring. It can be saved in a log file and supervised by any monitoring tool. When something happens with your application, I think the first thing you want to do is check the log to check what happens with your code. It's really important when we write logging in the right way and have enough information to serve that case.

Another case we can think about is that maybe in your sleep, the application caused some error for a specific case, it's a critical bug but not popular in our system. If you put in some logs in your code, the next morning will be very easy for you. Just check the log and find the reason why it happens.

Log Level Hierarchy

In most logging frameworks you will encounter some of the following log levels:
Severity affecting the system is arranged in order from top to bottom

Log type	Details
OFF	This log levels does not log anything. We will get no logging in our application
FATAL	This log usually use to show critical errors which can break down the server or the business logic is no longer working. A FATAL log level may be used when the system is not able to connect to a crucial data store like a database or payment system are not available or any executing function `breaks down` the system, `sys_error`,...
ERROR	The log level I'm using is very popular. This log is used when we `throw errors` in functions that we can catch or prevent at that time. This error can prevent one or more functionality next. Imagine that this log can use in your try-catch function and it affects the user experience.
WARN	The log level indicates that something `unexpected happened` in the application. The problems or issues that might disturb the process of the functionality. The application does not fail in this case. For example, passing the error occurred that the send notice function like webhook to partner.
INFO	The standard log level that `something happened`, the application entered to the specific state or just log to easily check again to make sure that steps working right. For example in this log, we can use the INFO of the request payment of the user, request authorization, and the result after calling from 3rd parties. Noted that the information in this log might not include the error.
DEBUG	The log usually use for developers to `debug` on the local / dev environment. It will be disabled in the production environment because it might be large. In specific cases, we also use this log on production. Less granular compared to the TRACE level but the developer use it every day. This log includes the information for `diagnosing issues` and `troubleshooting` or running on the test environment for the purpose of making sure everything is running correctly
TRACE	The most rarity case when we want to know what happening in your application and in side the third-party libraries that we use in our application. We can use this log to check the steps inside the algorithm in the library or you want to check what query calling to our database.
ALL	It is the combination of all other loggin levels. This log will log any logging levels that are defined.

Follow IBM documentations for logging levels, each level has an associated integer value usable by rules that monitor system mesages. View the detail values of each levels at IBM - Understanding logging levels

Logging levels format

We need to identify what is the suitable format for our system. I prefer some of these parameter in our log format (make sure it consistent in our application):

Timestamp: it will provide you with the order of the dozen of log (date or interger format).
Log levels name: look like INFO, ERROR, TRACE,... to make sure you can classify these log.
Message: the message you need to show. Make sure it use English language and friendly and it unique for each logs.

Example:

Do not write this code in our application if the outside does not have the try catch function:

try {
    // do something
} catch (err) {
    throw(err);
}

Conclusion

The log action is very important in our application. I don't want you to commit and push the code just to show the log because the error has been swallow.

Log can inform you not only how healthy your website is, but also how to calculate critical metrics like the error rate. Logs assist you in location the issue more quickly.