Home/About

Two hats,
one standard.

I build the tools, and I stand beside the people using them.

In short

Amaury Andrade is a product-minded full stack developer based in Belgium who designs, builds and integrates web, mobile and SaaS applications for small businesses, using Next.js, React, React Native, Node.js and Spring Boot.

[ 01 ]The story

Where it starts

I started out just wanting it to work.

Like most people, I learned by breaking things. A site that wouldn't render, a badly shaped database, a feature rewritten three times over. What those failures taught me isn't technical: a product never stands up on its own. It stands because someone understood what it was for before writing it.

So I stopped starting with code. I start with the uncomfortable question: what actually costs you time, today? The answer is almost never the one I was given on the phone.

How I think

Removing is a design decision.

"Less is more, let's refactor" isn't an aesthete's pose. It's a working method. Every extra screen is a screen to maintain, translate, test and explain. Every option added "just in case" is a decision handed back to the user.

So I spend a lot of time taking things out. Merging two pages that said the same thing. Deleting a setting nobody ever touched. What comes out is shorter to read, faster to load, and above all easier to change six months later, when I've forgotten why I wrote it that way.

Why small businesses

Most projects don't die of a technical problem.

They die because nobody translated a business need into product decisions. The owner knows what hurts; the developer knows what's possible; between the two, someone to arbitrate is almost always missing. That's the work I like best, and it's why I don't stop at handing over a Git repository.

A small business has no product team, no in-house designer, no time to burn in kickoff meetings. It needs someone who builds, explains, and steps back once it runs. The goal was never for anyone to depend on me. It's for this to hold without me.

[ 02 ]ConvictionsHow I think

Six rules I don't negotiate.

Non-negotiable rules, learned the hard way. With examples, of course: each one is the mark of a project where I did the opposite.

01The problem before the tool

Design and specification are written and signed off before the first line of code. We know what we're building, for whom, and what stays out.

In practice: the first call never mentions technology, and nothing gets built without a signed-off spec.

02Remove before adding

A feature you removed never breaks. Simplicity isn't a lack of ambition. It's a harder one.

In practice: I often propose cutting things out of scope.

03Ship small, ship often

Development moves in sprints, step by step, each one shipped to a URL you can open. A project that vanishes into a three-month tunnel always comes back slightly wrong.

In practice: a URL from week one, a release at every step.

04Performance is a courtesy

Making someone wait four seconds on a phone is deciding their time matters less than the developer's comfort.

In practice: the performance budget is set before anything is drawn.

05User experience isn't negotiable

Contrast, target sizes, keyboard, reduced motion, and above all a flow that holds up. "The customer is always right" never made a good product: if a choice hurts the experience, I say so, and we find better together.

In practice: I guide you on product and design, not just on code.

06Make people self-sufficient

An indispensable contractor is a risk, not a partner. What I build has to be pickable-up by someone else.

In practice: clear documentation and a hands-on handover.

The problem before the tool

Design and specification are written and signed off before the first line of code. We know what we're building, for whom, and what stays out.

In practice: the first call never mentions technology, and nothing gets built without a signed-off spec.

Remove before adding

A feature you removed never breaks. Simplicity isn't a lack of ambition. It's a harder one.

In practice: I often propose cutting things out of scope.

Ship small, ship often

Development moves in sprints, step by step, each one shipped to a URL you can open. A project that vanishes into a three-month tunnel always comes back slightly wrong.

In practice: a URL from week one, a release at every step.

Performance is a courtesy

Making someone wait four seconds on a phone is deciding their time matters less than the developer's comfort.

In practice: the performance budget is set before anything is drawn.

User experience isn't negotiable

In practice: I guide you on product and design, not just on code.

Make people self-sufficient

An indispensable contractor is a risk, not a partner. What I build has to be pickable-up by someone else.

In practice: clear documentation and a hands-on handover.

[ 03 ]Philosophy

What I believe, away from the code.

Care shows in what nobody notices

A right-sized gap, a transition that doesn't jump, an error message written like a sentence. Nobody will congratulate you for it. Yet that's exactly what separates a product you tolerate from one you enjoy opening.

Nothing solid gets built in permanent urgency

Urgency is sometimes real; making it the cruising speed is a management choice, and the product always pays for it. I'd rather name a later date and hold it.

Saying no in time is a service

Taking on a project you can't do well is stealing someone's time. Declining early, and explaining why, beats half a product delivered late.

Learn in public

I don't know everything, and pretending is expensive for everyone. "I don't know yet, let me look and come back to you" has always worked better than a confident front.

Technology is only worth what it enables

An elegant architecture that saves nobody any time is a private pleasure. What counts is the person at the other end, on a Tuesday morning, with something to get done.

[ 04 ]Outside the code

What feeds me, outside the code.

Working together is easier when you know each other a little. Here is what runs when the editor is closed.

01/04Music

Behind the decks

I mix on a DDJ-FLX4 with Rekordbox open. Building a clean transition and building an interface scratch the same itch: it all comes down to timing.

02/04Creative tech

Code that leaves the screen

Laser shows, generative imagery, web animations, 3D printing. I love it when the technical becomes something you look at.

03/04Thinking

Philosophy & self-development

I question how I work as much as I question my code. The convictions above come from somewhere: they come from that work.

04/04Gaming

Controller in hand

Baldur's Gate 3 at the moment. Good games are design lessons: they teach you their rules without ever opening a manual.

[ 05 ]How I work

Seven steps, always the same ones.

Understanding

One call, sharp questions. We pin down what actually costs you time or money. It's often not what you assumed going in.

Specification

We write down exactly what we're building: the scope, each stakeholder's business constraints, what stays out of bounds. Everyone signs off before we move on.

Architecture

The product's architecture: the data, the screens, the connections to your tools. Technical choices are made here, not mid-build.

Design, when needed

You see the product on screen before a single line of code exists. We fix things there, while fixing is still free.

Build

Regular releases on a URL you can open any time. No black box, no nasty surprise at the end.

CI/CD

Every change goes through an automated pipeline before it ships. Updating your product becomes a non-event.

Go-live and handover

Go-live, a user manual, hands-on handover. The goal isn't for you to depend on me. It's for this to run without me.

//The watchword

« Less is more, let's refactor. »

It isn't a profile tagline: it's what I repeat to myself when I feel like adding a feature that would only please me.

// spec sheet

StatusAvailable

FocusWeb · SaaS · SMBs

LanguagesFR · EN

Based inBelgium · remote

// tech stack

Frontend

ReactNext.jsTypeScriptTailwindVue.js

Backend

Node.jsJavaExpressPython

Data

PostgreSQLSupabaseMongoDB

Mobile

React NativeFlutter

Tools

DockerGitAWS

Let's work together.

A project, a question, an urge to modernise your business?
Write to me. I answer within 24 hours.

contact@amauryandrade.com

Let's talk about your projectView projects

Two hats,one standard.