Forem: Drilon Hametaj

Hardhat vs Foundry in 2026: Which Should You Use for Smart Contract Development?

Drilon Hametaj — Thu, 16 Apr 2026 16:02:28 +0000

I've used both Hardhat and Foundry in production projects. Smart contracts on Ethereum, Polygon, and BSC. Here's an honest comparison based on real experience, not documentation screenshots.

Hardhat: The JavaScript-Native Approach

Hardhat is the incumbent. Mature ecosystem, extensive plugin library, huge community. If you've done any Solidity development, you've probably used Hardhat.

What I like:

Plugin ecosystem (ethers.js integration, gas reporter, coverage, verify)
console.log in Solidity during development — this alone saves hours
TypeScript support for tests and scripts
Hardhat Network for local testing with mainnet forking What frustrates me:
Tests in JavaScript/TypeScript are verbose for testing Solidity
Compilation speed is noticeably slower than Foundry on large projects
Configuration can get complex with many plugins My Hardhat test for the SBT project:

import { expect } from "chai";
import { ethers } from "hardhat";

describe("SoulboundCertificate", function () {
  let sbt: any;
  let owner: any;
  let recipient: any;

  beforeEach(async function () {
    [owner, recipient] = await ethers.getSigners();
    const SBT = await ethers.getContractFactory("SoulboundCertificate");
    sbt = await SBT.deploy();
  });

  it("Should block transfers between addresses", async function () {
    await sbt.mint(recipient.address, "ipfs://test-uri");
    const [, , other] = await ethers.getSigners();

    await expect(
      sbt.connect(recipient).transferFrom(
        recipient.address,
        other.address,
        0
      )
    ).to.be.revertedWith("SBT: transfer not allowed");
  });
});

Foundry: The Solidity-Native Approach

Foundry (by Paradigm) is the challenger. Tests written in Solidity, blazing fast compilation, built-in fuzzing. It's what the cool kids use. But is it actually better?

What I like:

Tests in Solidity — you test Solidity WITH Solidity. No context switching.
Speed. Compilation and tests are 5-10x faster than Hardhat on the same project.
Built-in fuzzing with forge fuzz — essential for security
forge script for deployments is cleaner than Hardhat scripts
chisel REPL for quick experimentation What frustrates me:
Smaller plugin ecosystem
Less documentation and fewer Stack Overflow answers
Frontend integration requires more manual setup (no native ethers.js plugin)
Steeper learning curve if you're coming from JavaScript Same test in Foundry:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/SoulboundCertificate.sol";

contract SBTTest is Test {
    SoulboundCertificate sbt;
    address recipient = makeAddr("recipient");
    address other = makeAddr("other");

    function setUp() public {
        sbt = new SoulboundCertificate();
    }

    function test_BlockTransfer() public {
        sbt.mint(recipient, "ipfs://test-uri");

        vm.prank(recipient);
        vm.expectRevert("SBT: transfer not allowed");
        sbt.transferFrom(recipient, other, 0);
    }

    // Fuzz test — Foundry runs this with random inputs
    function testFuzz_MintToAnyAddress(address to) public {
        vm.assume(to != address(0));
        sbt.mint(to, "ipfs://test-uri");
        assertEq(sbt.ownerOf(0), to);
    }
}

Notice the fuzz test at the bottom. Foundry automatically runs it with hundreds of random addresses. This catches edge cases that manual tests miss. This is the kind of testing I apply in every smart contract audit.

My Recommendation

Use Foundry if:

Your project is primarily smart contracts
Security is critical (DeFi, high-value assets)
You want the fastest development cycle
Your team is comfortable with Solidity Use Hardhat if:
You're building a full-stack DApp with significant frontend
Your team is stronger in TypeScript than Solidity
You need specific plugins (e.g., hardhat-deploy, gas-reporter)
You're working with less experienced developers who need more resources What I actually do: I use both. Foundry for smart contract development and testing (faster, better fuzzing). Hardhat for deployment scripts and frontend integration (better ethers.js support). The two can coexist in the same project.

The Real Answer

The framework matters less than: writing comprehensive tests, running static analysis (Slither), doing fuzz testing, and having a proper audit before mainnet deployment.

A well-tested contract in Hardhat beats a poorly-tested contract in Foundry every time.

I'm Drilon, a blockchain and full-stack developer working with businesses on Ethereum, Polygon, BSC, and TON. More technical deep-dives on my blog.

3 Database Indexes Turned a 30-Second Query Into 0.4 Seconds

Drilon Hametaj — Thu, 16 Apr 2026 16:01:35 +0000

A client called me: "The order list takes 30 seconds to load." Their custom ERP was crawling. The hardware was fine. The problem was the code. Specifically, one query.

Here's what happened and how I fixed it.

The Setup

Stack: Node.js backend, PostgreSQL database, React frontend. The application was a custom ERP for a manufacturing company — orders, clients, products, invoicing.

The orders table had 2.1 million rows accumulated over 8 years. The query that powered the main order list page was doing a full table scan. Every. Single. Time.

The Query (Before)

SELECT o.id, o.order_date, o.status, o.total,
       c.company_name, c.vat_number
FROM orders o
JOIN clients c ON o.client_id = c.id
WHERE o.status IN ('pending', 'processing', 'shipped')
  AND o.order_date >= '2025-01-01'
ORDER BY o.order_date DESC
LIMIT 50 OFFSET 0;

Looks innocent, right? Let's see what EXPLAIN ANALYZE says:

Seq Scan on orders o  (cost=0.00..89543.21 rows=2100000)
  Filter: (status = ANY(...) AND order_date >= '2025-01-01')
  Rows Removed by Filter: 1987432
Planning Time: 0.2ms
Execution Time: 29847ms

Sequential scan on 2.1 million rows. No indexes on status, order_date, or client_id (the foreign key).

The Fix: 3 Indexes

-- Index 1: composite index for the WHERE clause
CREATE INDEX idx_orders_status_date
ON orders (status, order_date DESC);

-- Index 2: foreign key index (should ALWAYS exist)
CREATE INDEX idx_orders_client_id
ON orders (client_id);

-- Index 3: covering index for the most common query pattern
CREATE INDEX idx_orders_list_covering
ON orders (status, order_date DESC)
INCLUDE (id, total, client_id);

Index 3 is the secret weapon — a covering index. PostgreSQL can satisfy the entire query from the index alone, without touching the table (an "index-only scan"). The INCLUDE clause adds columns that aren't part of the search but ARE part of the SELECT.

After

Index Only Scan using idx_orders_list_covering on orders o
  Index Cond: (status = ANY(...) AND order_date >= '2025-01-01')
Planning Time: 0.3ms
Execution Time: 0.4ms

From 29,847ms to 0.4ms. Same data. Same server. Same query. Just proper indexing.

The Broader Pattern

In my experience building management software for SMBs, slow queries are the #1 performance complaint. And 80% of the time, the fix is the same:

Run EXPLAIN ANALYZE on every slow query
Add indexes for your WHERE clauses — if you filter by it, index it
Always index foreign keys — PostgreSQL does NOT auto-index FKs (unlike MySQL)
Consider covering indexes for your most critical queries
Monitor with pg_stat_user_indexes to see which indexes are actually used ## Common Mistakes I See

Too many indexes: every index slows down INSERT/UPDATE. Index what you query, not everything.

Indexing low-cardinality columns alone: a boolean is_active column with 99% true doesn't benefit from a standalone index. But it CAN benefit as part of a composite index.

Ignoring index order in composites: (status, order_date) is NOT the same as (order_date, status). Put the equality conditions first, range conditions last.

Never running VACUUM/ANALYZE: PostgreSQL needs updated statistics to choose the right query plan. If your stats are stale, even good indexes get ignored.

The Takeaway

Before blaming the hardware, the framework, or the database engine — check your indexes. The most impactful performance fix I've ever shipped took 3 lines of SQL and 10 minutes of analysis.

I build custom management software for Italian SMBs. Performance, security, and clean architecture are non-negotiable. Let's connect.

Building a Soulbound Token (SBT) System on Polygon — Full Walkthrough

Drilon Hametaj — Thu, 16 Apr 2026 16:00:17 +0000

I built a credential certification platform using Soulbound Tokens on Polygon. Not a tutorial project — a production system with thousands of certificates issued. Here's the full technical breakdown.

The Problem

A client needed to issue professional certifications that:

Could be verified by anyone, instantly, without calling the issuer
Could never be falsified or duplicated
Would persist even if the issuing company shut down
Would belong to the recipient, not to a centralized database PDFs fail all four criteria. A centralized database fails the last two. Blockchain solves all four.

Why Soulbound Tokens

Regular NFTs (ERC-721) can be transferred. That's the whole point of NFTs — ownership and transferability. But for credentials, transferability is a bug, not a feature. You don't want someone selling their medical license on OpenSea.

Soulbound Tokens are non-transferable NFTs. Once minted to a wallet, they stay there forever. The concept was proposed by Vitalik Buterin in the "Decentralized Society" paper.

Why Polygon

Gas costs. Deploying on Ethereum mainnet: $50-500 depending on congestion. Minting each certificate on Ethereum: $5-50. For a system that issues hundreds of certificates, that's unsustainable.

Polygon: deploy cost ~$0.01. Mint cost ~$0.001. Same Solidity code. Same EVM. Same security model (anchored to Ethereum).

For a deeper comparison, I wrote a full analysis of Polygon vs Ethereum for business use cases.

The Smart Contract

Here's the core of the SBT contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract SoulboundCertificate is ERC721, ERC721URIStorage, Ownable {
    uint256 private _nextTokenId;

    constructor() ERC721("SoulboundCertificate", "SBC") Ownable(msg.sender) {}

    function mint(address to, string memory uri) public onlyOwner returns (uint256) {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
        return tokenId;
    }

    // Block ALL transfers — this is what makes it "soulbound"
    function _update(
        address to,
        uint256 tokenId,
        address auth
    ) internal override returns (address) {
        address from = _ownerOf(tokenId);
        // Allow minting (from == address(0)) and burning (to == address(0))
        // Block all transfers between non-zero addresses
        if (from != address(0) && to != address(0)) {
            revert("SBT: transfer not allowed");
        }
        return super._update(to, tokenId, auth);
    }

    // Required overrides
    function tokenURI(uint256 tokenId)
        public view override(ERC721, ERC721URIStorage) returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public view override(ERC721, ERC721URIStorage) returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Key decisions:

OpenZeppelin base: never roll your own ERC-721. OpenZeppelin is battle-tested and audited.
_update override: in OZ v5, this is the single function that controls all token movements. Override it once, block transfers everywhere.
onlyOwner for minting: only the issuing organization can create certificates. No public minting. ## Metadata on IPFS

Certificate data (name, course, date, score) is stored as JSON on IPFS, not on-chain. On-chain storage is expensive and unnecessary for metadata.

{
  "name": "Advanced Solidity Development",
  "description": "Professional certification issued by [Organization]",
  "image": "ipfs://QmXxx.../certificate-image.png",
  "attributes": [
    { "trait_type": "Recipient", "value": "Mario Rossi" },
    { "trait_type": "Course", "value": "Advanced Solidity" },
    { "trait_type": "Date", "value": "2026-01-15" },
    { "trait_type": "Score", "value": "92/100" }
  ]
}

The tokenURI points to the IPFS hash. IPFS is content-addressed — the hash IS the content. If anyone changes a single byte, the hash changes. Tamper-proof by design.

The Frontend

Built with Next.js + Ethers.js. Two interfaces:

Admin Panel (authenticated, for the issuer):

Form: recipient wallet address, course details, date
Generates JSON metadata → uploads to IPFS → calls mint()
Dashboard of all issued certificates Public Verification (open to anyone):
Enter a wallet address → see all SBTs held by that address
Each certificate shows the full metadata pulled from IPFS
Link to the transaction on Polygonscan for on-chain proof

// Simplified verification logic
const provider = new ethers.JsonRpcProvider(POLYGON_RPC);
const contract = new ethers.Contract(SBT_ADDRESS, ABI, provider);

const balance = await contract.balanceOf(walletAddress);
const certificates = [];

for (let i = 0; i < balance; i++) {
  const tokenId = await contract.tokenOfOwnerByIndex(walletAddress, i);
  const uri = await contract.tokenURI(tokenId);
  const metadata = await fetch(uri.replace('ipfs://', IPFS_GATEWAY));
  certificates.push(await metadata.json());
}

Testing

Full test suite with Hardhat:

describe("SoulboundCertificate", () => {
  it("should mint to recipient", async () => {
    const tx = await sbt.mint(recipient.address, "ipfs://test");
    expect(await sbt.ownerOf(0)).to.equal(recipient.address);
  });

  it("should block transfers", async () => {
    await sbt.mint(recipient.address, "ipfs://test");
    await expect(
      sbt.connect(recipient).transferFrom(recipient.address, other.address, 0)
    ).to.be.revertedWith("SBT: transfer not allowed");
  });

  it("should allow burning by owner", async () => {
    // Revocation mechanism — issuer can burn if needed
  });
});

Plus Slither for static analysis and manual review for logic bugs. I wrote about my full smart contract audit process separately.

Results

Deployed on Polygon mainnet
Thousands of certificates issued
Verification time: ~3 seconds (vs days for traditional verification)
Cost per certificate: < $0.01
Zero downtime since launch ## When to Use This Pattern

SBTs make sense for: professional certifications, academic credentials, membership badges, compliance attestations, and any credential that should be permanent, non-transferable, and publicly verifiable.

They don't make sense for: temporary access tokens, transferable assets, or anything where privacy is critical (blockchain is public — consider ZK proofs if privacy matters).

I'm a blockchain developer building smart contracts, wallets, and DApps for businesses. If you're working on something similar, let's talk.

Why Software Is Not a Technical Choice — It’s a Business Strategy

Drilon Hametaj — Mon, 08 Dec 2025 12:17:27 +0000

Most people think of software as a technical decision.
Frameworks.
Stacks.
Performance.
Databases.

But after working with many companies, I’ve learned something very different:
choosing software is not a technical choice.
It’s a strategic one.

Growth Breaks First Behind the Scenes

Many businesses grow by:

working more hours
taking more clients
moving faster

At first it works.
Then something breaks.

Requests get lost.
Deadlines are missed.
Information is scattered.
People start asking:
“Who is doing what?”
“Where is that file?”
“Did anyone answer that client?”

Growth usually doesn’t break in marketing.
It breaks in operations.

Chaos Is Expensive (But Invisible)

Operational chaos is dangerous because:

it doesn’t show up immediately
it slowly erodes margins
it increases stress and errors
it makes every decision harder

And yet many companies accept it as “normal”.

It shouldn’t be.

Software as a Business Lever

Good software allows you to:

centralize information
reduce manual errors
automate repetitive actions
make decisions based on data, not intuition

Bad software does the opposite:

adds complexity
creates friction
slows people down

That’s why software is strategy, not just technology.

My Work Starts Here

My work doesn’t start with writing code.
It starts with understanding:

workflows
bottlenecks
decision points
real business problems

Only after that does the technical part begin.

If you want to see the type of projects I work on today, you can find them here:
👉 https://www.drilonhametaj.it

Final Thought

You can have the best marketing in the world.
But if your internal systems are weak,
your growth will always be fragile.

Strong business needs strong systems.

Building a Vertical SaaS for Construction Companies: What I Learned from the Real World

Drilon Hametaj — Mon, 08 Dec 2025 12:15:56 +0000

When people think about construction companies, they often imagine cranes, workers, concrete and noise.
What they rarely think about is software.

And yet, after talking with dozens of small and medium construction companies, I realized something surprising:
most of their biggest problems are not on the construction site.
They are behind a computer.

Spreadsheets everywhere.
Costs tracked manually.
Invoices compared at the end of the job.
Profit discovered… too late.

The Excel Illusion

Let’s be clear: Excel is a powerful tool.
It works perfectly when:

you have a single project
one person manages everything
data doesn’t need to be shared in real time

The problem starts when:

multiple construction sites run at the same time
several people enter data
costs change daily
variations keep coming in

At that point, Excel stops being a solution and becomes a risk.
One wrong formula, one outdated file… and your financial data is no longer trustworthy.

The Real Business Problem

The real issue I kept seeing was always the same:
construction companies often don’t know their real profit in real time.

They know:

how much the client should pay
roughly how much workers cost But they don’t have:
live cost tracking
automatic margins
real-time profitability per project

From a business standpoint, this is extremely dangerous.

Why I Decided to Build a Vertical Tool

This is why I decided to build a vertical SaaS specifically for construction companies.
Not a generic ERP.
Not yet another spreadsheet replacement.
But a tool focused on:

estimates
job progress (SAL)
real costs
workers
suppliers

The goal is simple:
give small construction companies the same level of control that only large companies usually have.

If you’re curious about the project itself, this is where it lives:
👉 https://www.ediliziami.pro

What I’m Learning as a Founder

The biggest lesson so far is this:
real-world businesses don’t behave like textbooks.

Every company:

uses different workflows
has different habits
resists change in different ways

The technical challenge is easy.
The human challenge is the real product.

Final Thought

Digital transformation is not about AI, blockchain or buzzwords.
It’s about solving boring, painful, daily problems better than before.

And boring problems usually hide the best SaaS opportunities.

Come ho creato TrovaMi.pro con l’AI (in 48 ore)

Drilon Hametaj — Thu, 10 Jul 2025 08:48:04 +0000

Come ho creato TrovaMi.pro con l’AI (in 48 ore)

📌 TL;DR: Ho creato TrovaMi.pro in 48 ore sfruttando l’intelligenza artificiale per aiutare freelance, agenzie e professionisti a trovare lead validi e analizzati. È un tool semplice ma potente, nato da un bisogno reale. E no, non è l’ennesimo CRM.

💡 L’idea

Tutto è iniziato da una frustrazione. Ogni volta che dovevo trovare nuovi clienti, perdevo ore su Google, Google Maps, Pagine Gialle, forum, gruppi Facebook... sempre la solita storia: informazioni incomplete, siti non aggiornati, recapiti sbagliati.

Mi sono chiesto:

"Ma se esistono tool per tutto, perché non esiste un tool che trova per me potenziali clienti, li analizza e me li propone pronti per essere contattati?"

Boom.

Nasce l’idea di TrovaMi.pro.

⚙️ Come funziona

TrovaMi è una piattaforma web (Next.js + Supabase + Playwright/Puppeteer per lo scraping) che permette:

✅ Trovare aziende con sito, social e presenza online
✅ Analizzarle automaticamente (SEO, performance, privacy, pixel Facebook, dominio, ecc.)
✅ Filtrare i risultati in base al proprio settore (es. agenzie marketing, web developer, consulenti, ecc.)
✅ Salvare e gestire i contatti con un piccolo CRM integrato (solo per piani PRO)

Il tutto con un’interfaccia ispirata a Apple e Linear: elegante, chiara, veloce.

🛠️ Tech stack

Frontend: Next.js + Tailwind + Shadcn
Backend: Supabase (Postgres + Auth + Edge Functions)
Scraping Engine: Playwright + Puppeteer, orchestrato da GitHub Actions
Cache: sistema di crediti per limitare e bilanciare gli accessi

🧠 Il tocco dell’AI

Gran parte del progetto è stato scritto (e riscritto) usando Copilot Agent 4 e Claude 4.

Li ho usati per:

Generare lo scraping engine
Scrivere analisi SEO/performance/cookie
Creare UI eleganti senza perdere tempo sul CSS
Avere sempre uno sparring partner tecnico per ragionare sulle architetture

Onestamente, senza l’AI ci avrei messo settimane. Con l’AI: 2 giorni.

🎯 Per chi è

👨‍💻 Freelance stanchi di cercare clienti a mano
📈 Agenzie marketing che vogliono vendere servizi SEO, Ads o branding
🧑‍🏫 Professionisti locali (avvocati, commercialisti, coach) che cercano clienti nel proprio territorio
👀 Chi fa outreach, ma vuole farlo meglio, più mirato

💸 Modello freemium

Gratuito: 2 crediti al mese
19€/mese: 25 crediti
49€/mese: 100 crediti + CRM

In più, si possono acquistare pacchetti una tantum (es. 30 crediti a 9€).

🚀 Il mio obiettivo

Rendere la ricerca clienti semplice, veloce e umana.

Non è l’ennesimo tool pieno di feature inutili: è uno strumento concreto, pensato per essere usato ogni giorno.

🙌 Provalo e fammi sapere

👉 www.trovami.pro

Se lo provi, scrivimi: ogni suggerimento può migliorarlo.

E se vuoi aiutarmi a farlo conoscere, condividilo con chi lavora online.

EdiliziaMi: Un gestionale moderno per la complessità dei cantieri

Drilon Hametaj — Tue, 18 Feb 2025 15:32:12 +0000

La gestione dei cantieri edilizi è notoriamente difficile: materiali che tardano, ordini mal comunicati, team frammentati. Eppure, in un mondo in cui la digitalizzazione sta semplificando processi in ogni settore, il panorama edile rimane spesso bloccato in metodi obsoleti. La domanda diventa quindi: come possiamo applicare le migliori pratiche del software engineering e del product design a un settore tradizionale come l’edilizia?

EdiliziaMi nasce con l’intento di portare ordine in questo caos. Con un approccio orientato agli sviluppatori e tecnologie moderne, stiamo costruendo una piattaforma che trasforma la gestione del cantiere in un processo fluido e prevedibile.

Tecnologie e architettura:
Alla base di EdiliziaMi c’è un’architettura a microservizi che garantisce scalabilità e modularità. La scelta di questa architettura è motivata dalla necessità di adattarsi rapidamente alle esigenze specifiche delle imprese edili, che variano per dimensione, tipi di progetti e workflow operativi. Alcuni dettagli tecnici:

Backend:
NestJS: utilizzato per creare un backend modulare e scalabile.
Database: un’architettura ibrida che combina un database relazionale per la contabilità e uno NoSQL per gestire dati semi-strutturati come ordini, note di cantiere e report.
Event-driven architecture: utilizziamo Kafka per gestire eventi critici, come aggiornamenti in tempo reale degli ordini e notifiche per gli utenti.
Frontend:
Flutter: scelto per il frontend, garantisce un’esperienza utente fluida e un’unica codebase per iOS, Android e web.
Material Design: implementato per offrire un’interfaccia familiare, pulita e altamente responsive.
Sfide tecniche e soluzioni:

Integrazione di dati eterogenei:
I cantieri generano dati non strutturati (foto, note vocali, annotazioni su planimetrie) e dati altamente strutturati (ordini di acquisto, registri di ore lavorate). EdiliziaMi utilizza schemi JSON flessibili per raccogliere e organizzare i dati semi-strutturati, mentre i dati finanziari e contabili sono normalizzati in un RDBMS.

Sicurezza e affidabilità dei dati:
Con dati sensibili come piani di costruzione, informazioni finanziarie e ordini di materiali, la sicurezza è fondamentale. EdiliziaMi implementa un sistema di autenticazione basato su JWT con refresh token, crittografia dei dati.

Modularità per adattarsi a diverse imprese:
Non tutte le aziende edili hanno gli stessi processi. Il design modulare dei microservizi consente di attivare solo le funzionalità necessarie, evitando sovraccarichi di configurazione e rendendo la piattaforma accessibile anche alle piccole imprese.

Perché EdiliziaMi è diverso:
Il nostro approccio parte dall’idea che la gestione del cantiere non deve essere un peso. Pensiamo che applicare pattern moderni di sviluppo software, un’architettura robusta e strumenti scalabili possa trasformare radicalmente il settore edile. Non è solo un gestionale: è un ecosistema costruito con gli stessi principi che rendono le migliori piattaforme software affidabili, performanti e facili da usare.

EdiliziaMi non è una semplice digitalizzazione di processi esistenti. È una reingegnerizzazione della gestione del cantiere, unendo le esigenze pratiche del settore edilizio con le migliori tecniche di sviluppo software. Se siete curiosi di scoprire come questo approccio può rivoluzionare il lavoro di chi opera nei cantieri, seguite il nostro progetto su GitHub e iscrivetevi alla nostra lista d’attesa per essere tra i primi a provare EdiliziaMi.
https://ediliziami.pro