About
I usually start with a process that is not working, not a technology receiving attention.
I am Thiên Thành (BrianV), a product builder, CTO and Co-Founder of ZiniSoft. Across 15 years in business software, I have focused on turning real operational problems into systems that can be observed, controlled and improved.
Product builder15 years in softwareCTO & Co-Founder

Professional story
Seven years with Kindie changed how I see a product.
Kindie is a product I have worked with for 7 years. That is long enough to see that a product is not simply built and finished. It has to change with its users, its workflows and the situations that only appear when a system is operated every day.
Products such as OmniSpa, SavvyBot and Intake are other examples of the same way of thinking: start with the work as it happens, make ownership clear and only then decide where software or AI should participate.
One lesson I had to learn is that automating an unclear process does not make the team clearer. It only moves ambiguity faster and makes it harder to trace.
How I work
I need to understand the work before delegating it to a machine.
- 01Operational signal
- 02Process and ownership
- 03Standardize or build
- 04Bounded automation
- 05Observable outcome
Before asking where a business can use AI, I usually clarify five questions:
- What signal shows that the process has a problem?
- Where is the work blocked?
- Who needs to keep the decision?
- Which part can software or AI support safely?
- What evidence would show that the result is actually better?
Only then do I work with the team to decide whether to standardize the process, use an existing product, build software or automate a carefully bounded part. Decisions affecting money, data, access or reputation always need a responsible person.
Public learning
I share what is working and what has to be rebuilt.
I do not write to prove that every system succeeds on the first attempt. Operator Notes, case studies and demos are how I record the decisions made, the limits accepted and the evidence available.
To make the work inspectable, I separate production from experiments, describe my role apart from the work of the team and use measurements only when the definition, period and source are clear.
I share simplified diagrams to explain the reasoning. Internal architecture, customer data and private information remain outside the public record.
If a real process is costing your team time
We can begin by clarifying whether the problem is in the workflow, data, ownership or tooling; only then decide what to standardize, build or automate.