I follow the problem. All the way down.

Raymund Zyron Abella / Software Engineer / Cebu City, Philippines

I’m Raymund, a software engineer in Cebu City. I build the part people interact with, then work through the services, data, and tools that make it behave. Some projects become products. Others become a way to understand a difficult idea by making it real.

378 builds and experiments. 21 articles.

The interesting part is how it holds together.

A polished screen is a good beginning. I’m just as interested in what happens after someone presses Save: where the change lives, what happens when the connection drops, and whether trying again creates the same result twice. Those questions shape both the interface and the system behind it.

That is the thread through an intentionally varied archive. There are compact mobile tools and browser experiments alongside interpreters, a database, and a small language model. Working at different scales gives me more ways to recognize a problem and choose an appropriate solution.

I keep the context with the work: what I built, where collaborators or upstream projects contributed, which constraints remain, and what someone can actually try. An experiment and a deployed product can both be useful; they need different expectations.

A screen is a promise about what the system can do.

Different scales. The same curiosity.

Fieldwork

An application tests its foundations

Fieldwork brings several of my tools into one working application. Zyra handles the reactive interface, Ryft checks typed backend data, and ZeeDB stores the records. A Node adapter connects the parts where their current interfaces do not meet directly.

The useful challenge is the space between them. An offline edit needs a durable local record before it can become a backend-accepted change. A retry needs an identity. A missing capability needs an explicit boundary. Building the application exposes the assumptions that isolated demos can leave untouched.

A local personal workspace built with Zyra, Ryft, ZeeDB, and a Node adapter.

Explore the project / Read the story

RAGret–ALMA

Built together, tested in public

RAGret starts with a familiar team problem: remembering the decision while losing the conversation and evidence behind it. The project connects conversations, reference documents, and decisions in an inspectable graph, then uses that retained context to support answers with citations.

Our KodoTech team won second place at Future Forge: The ALMA Hackathon in Cebu on October 22, 2026. I built alongside John Lorenzo and Jhon Paul. The outcome matters to me alongside the engineering question: can another person follow an answer back to the source that supports it?

Team-built decision memory. Second place at Future Forge: The ALMA Hackathon.

Explore the project / Read the story

Gloopy

A small model, an inspectable process

Gloopy is an alien character language model trained from scratch and run in the browser. Its 8.7 million parameters and 128-token context window make the scope tangible: short character replies, a narrow dataset, and clear limits.

The project connects dataset preparation, tokenization, training, export, and inference. I like being able to follow that entire path. A strange answer becomes something to investigate in the data or model, rather than an unexplained result from an API.

8,726,016 parameters. A 128-token context. Inference in the browser.

Explore the project / Read the story

How I take a project apart.

1. Find the actual job.

   Start with the action someone needs to complete. Follow the awkward steps, the information they need, and the point where the current workflow breaks down. A useful scope is more valuable than a long feature list.

2. Make the state explicit.

   Define what saved, pending, accepted, and failed mean. Separate user intent from network success. These distinctions belong in the data model and in the words the interface uses.

3. Follow one path end to end.

   Connect an input to validation, persistence, and a visible result. Make the boundaries inspectable before expanding the surface area. The architecture should explain the behavior someone can observe.

4. Test the uncomfortable cases.

   Disconnect. Retry. Send malformed input. Look at recovery and cleanup. Keep the requirements and remaining limitations next to the implementation so someone else can judge the work on its actual terms.

The questions I keep coming back to.

The tools change. These questions continue to lead me into worthwhile work.

• What should keep working when the connection disappears?
• Which guarantees belong in the language, runtime, or database?
• How small can a model be and still do one useful job?
• Can someone inspect the evidence behind an automated answer?

That is what connects the breadth of the portfolio: a habit of building, looking closely at the result, and taking the next question seriously.

Tell me what you’re building.

A useful tool, a difficult workflow, or a system that needs a clearer shape. I’m interested in the problem behind the brief.