What is sbsepul.dev?
I have been using sbsepul for a long time. It is short, practical and close enough to my name that it feels like mine without needing to explain too much. Sebastian Sepulveda became sbsepul in the same way many developer names are born: from handles, emails, GitHub accounts and years of typing the same identity across tools.
That is why I like the idea of sbsepul.dev. It sounds like a small place where my work can live without pretending to be a company, a personal brand or a polished media site.
I want it to feel more like a public notebook with enough structure to be useful.
Why I want this site
Most of my work lives in repositories, experiments, notes, dashboards and half finished ideas. That is normal, but it hides the most interesting part: why something was built.
A GitHub repo can show code. A deployed app can show the final surface. A CV can show dates and roles. None of those explains the path between a problem and a solution.
That is what I want this site to do.
I want to write about the problems I am seeing, the products I am building, the technical decisions that mattered and the parts that still feel unresolved.
What I want people to know before reading
My background is in computer science, data science and data engineering. I have worked with data pipelines, cloud platforms, machine learning systems and computer vision research.
But I am increasingly interested in the space where engineering becomes a product decision.
That is why the projects here are not only technical demos:
- Kibura is about family health tracking and the problem of keeping daily records organized.
- Dream Home is about making housing decisions easier to compare in Chile.
- AI Memory Vault is about not losing the history created while working with coding agents.
- My computer vision research is about using models to accelerate expert review instead of replacing interpretation.
Those are different domains, but they share the same pattern: a messy workflow becomes clearer when the system remembers the right things.
What I want to publish
I do not want every article to be a tutorial. There are already enough tutorials.
I want to write posts that explain:
- what problem I am trying to solve
- why existing tools feel incomplete
- what I decided to build
- how I use it myself
- how someone else could adapt the idea
- where the limits are
Sometimes that needs code. Most of the time it needs a better explanation of the problem.
Why keep it public
Writing publicly forces a cleaner version of the idea. If I cannot explain why a project exists, the project is probably not clear enough yet.
It also gives people a way to know me through the work. Not only through a title like Data Engineer, but through the decisions I care about: useful systems, practical automation, data that can be trusted, and AI tools that make engineering memory easier to use.
That is the version of sbsepul.dev I want to build.
Not a finished portfolio. A place where the work becomes easier to understand.
References
Enjoyed the article? Share it with others!