Vahid

Senior Software Engineer • Co-founder @MyOvandor
I share lessons from building software, AI products, and startups.

[Vahid @vahideng87]

We just launched Ovandor on Product Hunt.

If you’re awake with us right now, come see what we’ve spent the past year building and tell us what you think.

https://t.co/SM3egf9GPn

[Vahid @vahideng87]

@Joi2James https://t.co/NmeILw0jfm

[Vahid @vahideng87]

@Joi2James Building Ovandor, a Personal Intelligence product. We are working on how useful thinking gets lost between notes,

[Vahid @vahideng87]

@lukmanAufbau Yes. Distribution is the fastest way to find the part of the product that still needs work. Waiting for good enough usually means waiting for evidence you can only get from real users.

[Vahid @vahideng87]

@attacomsian Quitting gets clearer when the project keeps consuming attention without producing new evidence. The cost is not only time. It is the decisions you stop making while protecting the old one.

[Vahid @vahideng87]

@oleks01 Working across fields changes the questions you notice. A developer who has seen the warehouse or support workflow can often spot the real constraint before turning it into another feature request.

[Vahid @vahideng87]

@MarkoCirix Bootstrapping buys you time to learn what customers will pay for before the company has to optimize for a larger story. That can matter more than the capital itself.

[Vahid @vahideng87]

@rihntv No distribution hides a product problem for longer. Bad product makes every distribution channel more expensive because the signal from new users gets weaker.

[Vahid @vahideng87]

@CodeWithTamara Shipping first and learning the infrastructure underneath is a normal path. The useful point is knowing which parts you can safely abstract and which failures you need to understand yourself.

[Vahid @vahideng87]

@santoshstack Developers usually avoid sales when the conversation feels like performance. Showing the problem clearly and asking one useful question makes the work feel more like product discovery.

[Vahid @vahideng87]

@does_it_code Agent tools need task-shaped contracts, not frontend-shaped payloads. A list-users tool should force filters, projections, and a hard result limit before execution, so one broad request cannot pull 14,000 rows of irrelevant state.

[Vahid @vahideng87]

@jidesakin_ AI review becomes noisy when the reviewer has no change specific risk model. Giving it the contract, affected boundary, and two or three failure modes to inspect produces something closer to a focused review than a generic lint pass.

[Vahid @vahideng87]

@itskamrankhan The hardest part is deciding what evidence closes the task. Prompts, debugging, review, and tests all improve once the agent has a concrete failure signal and a stop condition. Without those, every stage becomes another opinion.

[Vahid @vahideng87]

Owning the loop requires more than combining tools. The useful boundary is whether the agent can observe a failure, choose the next diagnostic action, and produce evidence that the change fixed the right thing. Otherwise the IDE is integrated but the judgment loop is still manual.

[Vahid @vahideng87]

@gregorojstersek The durable part is linking each action item back to the decision or feedback that created it. Without that context, a week later the owner knows what to do but not why the tradeoff was made.

[Vahid @vahideng87]

@ardmn___ The hard part shifts into defining boundaries the agent can work inside. Architecture and decomposition become executable context, and maintenance gets easier only when the generated change leaves its intent visible in the code.

[Vahid @vahideng87]

AI agents need a definition of done outside the agent.

For a code change, that can mean passing tests, reaching the expected UI state, and producing a reviewable diff.

When the system does the work and declares success, a convincing explanation can hide a broken result.

[Vahid @vahideng87]

A meeting note is rarely useful by itself.
Its value is in the decision it explains, the assumption it records, or the open loop it leaves behind.
Ovandor is built to surface those connections when they can still change the next action.

[Vahid @vahideng87]

@JamesUchechi6 The distinction matters because most production failures sit at the boundaries between those layers. A strong model cannot compensate for unclear state ownership, weak completion checks, or memory retrieved without a reason. Agent engineering needs those contracts to be explicit.

[Vahid @vahideng87]

Most notes arrive with context: a meeting, a decision, or an unanswered question.
Weeks later, the note is still there. The context that made it useful is harder to recover.
Ovandor is built to surface those connections before you need to search for them.

[Vahid @vahideng87]

@ChainReactConf @amazon Useful personalization depends less on the model than on what you refuse to overreact to. If every click rewrites the feed, you are optimizing for recent noise instead of stable intent. The hard product work is deciding which signals deserve memory and which should decay fast.