Bring me the problem.
You get the product working.
I'm Luis, a full stack developer in Barranquilla. Custom software: web applications, mobile apps, the backend holding them up, and automation that takes manual work off someone's hands. I come in while the problem is still just words and take it to production alongside the team already working on it.
- Last role
- Full Stack · Kymbo Devs
- Feb – Dec 2025 · Remote
- Experience
- 3+ years
- Web, mobile, backend and automation
- Core stack
- TypeScript · Python
- NestJS · React Native · Postgres
The hard part is almost never the code.
I started programming in 2022, and the first real client taught me what no tutorial does: writing it is the easy half. What decides whether a project goes well is how much you understood before typing — and who you asked.
Since then I have worked inside Agile teams, with clients who don't speak in technical terms, and on code somebody else wrote before I got there. I cover the whole product — data, backend, interface and deployment — and what that is really good for is talking to anyone on the team in their own language, so a problem never sits waiting between two areas.
I ask before I build
What someone asks for and what they need are rarely the same thing. I push until the request makes sense, because finding that out during the demo means building the same screen twice.
We agree the order, then I defend it
What gets built first, what can wait, and what stays out of this version. I would rather argue about it in a document than in a pull request.
Consistency over intensity
A project does not get finished in bursts of energy, it gets finished with rhythm: something to show at every check-in, instead of a weekend spent rescuing it.
Featured Projects
Both reached production and are still standing. For each one I would rather tell you the decision that was hard to make than read out the feature list.
Trayko
Ride-sharing for people who already make the same trip every day: one publishes the ride, the others book a seat. I built all four pieces — the React Native/Expo app, the NestJS API, the admin panel and the marketing site — on top of a PostgreSQL schema I modeled before writing the first screen, because a trip with seats, bookings and cancellations does not forgive a badly designed table.
account_treeArchitecture Challenge
The seat is booked before it is paid for. The driver accepts, the passenger gets a window to pay, and if the money never arrives the seat frees itself. That single rule drags in everything else — charging, refunding, verifying who is driving, proving who boarded — and all of it still has to add up when two people book in the same second.
trending_upImpact & Architecture
Streaming CRM
Streaming resellers live by dates: every account expires on a different day and forgetting one loses the customer. This SaaS turns that mental notebook into inventory, customers, subscriptions and renewals, with a dashboard built around the only question that matters at month end — what came in, what renews next, and which account nobody is using.
speedResult
hubTechnical Focus
Into the queries. A dashboard that sums revenue, groups expiry dates and cross-references account usage will drag the database down with naive reads, so the real effort went into the relational model and the indexes behind each card — not into the cards.
Professional Trajectory
In reverse, which is how it gets told. What I did is on the CV; below is what I started doing differently afterwards.
Full Stack Developer
A year building inside Agile teams for the agency's clients: REST APIs in NestJS and FastAPI over PostgreSQL schemas of my own, agents with LangChain, LangGraph and OpenAI, and Shopify modules kept alive in Remix. The lesson: an AI feature falls over for the same reasons any backend does — data nobody modeled and inputs nobody validated.
APIs over data I designed
Writing the endpoint and modeling the table in the same pass changes both. The API comes out simpler, because the schema already answers the question the endpoint was about to solve by hand.
Agents that were not demos
LangGraph to orchestrate the steps, RAG and vector databases so the model answers with the company's documents instead of what it remembers from the internet. Automating a process someone was already doing — not a chat that replies nicely.
Freelance Full Stack Developer
A year of custom web applications for local businesses in Barranquilla. No PM and no QA in between: the client describes the problem in their own language, and translating it is on you before anything gets built. The lesson: almost nothing that goes wrong is technical.
- checkEvery project end to end — understanding the business, picking the stack, building it, deploying it, and still being there when something broke at nine at night.
- checkI learned to teach the client how to use what I handed over. A system the owner cannot touch comes back forever as unpaid support.
- checkReact on the front, my own REST APIs behind it, with performance and SEO treated as part of the job rather than an extra billed separately.
Web Developer
My first job with code that already existed and users who were already there. Maintaining corporate sites and building WordPress stores teaches something no greenfield project can: how to read what someone else wrote and not break it.
- checkMaintained corporate websites and shipped changes requested by stakeholders who did not speak in technical terms — translating the request was half the task.
- checkBuilt sites and e-commerce stores in WordPress, tuning load time and experience. That is where I understood that one extra second is one less sale, and that users do not forgive what developers file under detail.
Technical Arsenal
A list of technologies says very little — anyone can paste logos. These are the ones I work with daily and keep alive in production. When a project needs something else I go and learn it; what I do not do is debut it inside a client's codebase.
Frontend & Mobile
devicesBackend & APIs
dnsData
databaseCloud & DevOps
cloudAI & Emerging Tech
psychologyThe AI I care about is not the chat box; it is the tedious process someone repeats by hand every day. That means deciding when a model earns its place and when a SQL query is enough. Most of the time the query is enough, and knowing which case you are in is the whole skill.
Core Work
Philosophy
Not poster quotes. These are the two things I learned by paying for them, and the only two I will hold up an architecture meeting over.
“The schema is the architecture. Everything above it is negotiable — a badly modeled table isn't.”
“An agent with no plan for the moment the model fails isn't a feature. It's a lucky demo.”
Let's build something
great together.
If you already know exactly what to build, anyone can build it. What I am best at starts earlier: working out what the product has to solve and what can be left out. Write to me and you will have an answer within 24 hours — and if I am not the right person for it, I will say so.