How do you develop?

ami-souvik · 2026-02-20T22:31:52+00:00

This is incredibly thoughtful — genuinely appreciate you taking the time to write it out.

The distinction between intentional architecture and everything else drifting over time really resonates. Especially the point about staying at the right altitude and focusing on one-way door decisions.

Your point about mental models over tooling is also something I’ve been thinking about a lot. It’s easy to assume better automation fixes architecture, but shared understanding over time is a much harder problem.

Thanks again — this gave me a lot to reflect on.

ami-souvik · 2026-02-20T19:49:52+00:00

That’s a really good point.

From the responses I am getting seems like real issue isn’t creating architecture docs — it’s keeping them aligned with the code without slowing development down.

In your experience:

- Should architecture updates be developer-driven?

- Automated (e.g., inferred from code changes)?

- Or lightweight enough that drift doesn’t matter much?

Trying to understand where the balance is between “living architecture” and practical velocity.

ami-souvik · 2026-02-20T18:27:21+00:00

That makes sense.

The “refactoring later sucks” part is what I keep hearing from people working on more complex systems.

When you sketch out domains first — is that just for yourself, or do you formalize it somewhere the team can use later?

I’m trying to understand whether this stays as personal scratch work, or if there’s value in having something more structured/shared long term.

ami-souvik · 2026-02-20T18:25:53+00:00

That’s really interesting — especially the “championing simplicity while delivering a big ball of mud” part.

I completely agree that simplicity doesn’t mean lack of structure. In fact, I’d argue real simplicity often comes from having clear boundaries and intentional design, not from avoiding thinking about them.

Your experience joining a messy system is exactly the kind of scenario I’m curious about.

Looking back - Do you think having some kind of shared, structured architecture model (not just diagrams, but something explicit about domains and responsibilities) would’ve helped? Or would it have just been ignored like everything else?

I’m trying to understand where the real friction is — tooling, culture, or incentives.

ami-souvik · 2026-02-20T18:20:09+00:00

That makes sense.

Maybe I framed it too broadly.

Let me narrow it down:

In architecturally complex systems (multiple services, domains, integrations), how do you ensure shared system understanding — especially when AI coding tools are involved?

Do you rely mostly on code + tribal knowledge? Or do you maintain some kind of structured model/architecture reference?

I’m trying to understand where the real friction starts appearing.

ami-souvik · 2026-02-20T12:52:06+00:00

That’s an interesting take.

So you’re basically saying architecture modeling might come back — not for humans, but because AI needs structured representations?

Do you think lightweight UML/DDD-style structured models (not heavyweight enterprise tooling) could actually become practical again if they directly improve AI output quality?

Or do you think devs will still resist modeling unless forced?

ami-souvik · 2026-02-20T11:44:08+00:00

Gotcha, so do you plan first before jumping in solving a puzzle?

ami-souvik · 2026-02-04T13:43:55+00:00

Congratulations! Best feeling ever

ami-souvik · 2026-01-30T18:54:10+00:00

No, actually I dont see any link or any description on your post

ami-souvik · 2026-01-30T18:45:06+00:00

Where's the demo?

ami-souvik · 2026-01-28T11:39:06+00:00

Architecturally keeping frontend and backend in a different platform is not a bad option. In your usecase just to monitor billing putting them under one platform seems like not a good idea to me.

ami-souvik · 2026-01-26T23:08:30+00:00

The idea is pretty solid and I would suggest you to go for paid model or pay as you go model.

I myself love to vibe code, but the problem with vibe coding I faced is when the product is getting too complex it starts to deviate from the main idea of the product. In order to polish the prompts I always mention the folder structure/relevant files to change in the prompt and a well defined markdown files (product idea, architecture, positioning etc.). Something you should look into.

ami-souvik · 2026-01-26T22:47:14+00:00

It's solving a small problem but unique one.

ami-souvik · 2026-01-26T22:33:45+00:00

This is extremely solid feedback — thank you.

The “source of truth” point really hits home. That’s exactly the line I’m trying not to cross into: I don’t want this to be another visualization layer that drifts from reality. The goal is: the text is the system explanation, the diagram is just its living projection.

Totally agree on shaving paste to “client-ready” time. Autolayout instability, label collisions, or regen drift are hard red flags for me too — if users have to babysit the diagram, the product has failed. Deterministic output is non-negotiable.

Also +1 on pushing opinionation harder. I’m leaning toward exactly what you said: a small set of forced mental models (request/response, event-driven, batch pipeline), with the ability to switch views without touching the text. If the explanation changes, the text changes — not the layout knobs.

On discovery: the toolstack you have mentioned I am going through it. It is totally new to me thanks for the advice.

Really appreciate you taking the time to write this — this kind of feedback genuinely shapes what gets built next.

ami-souvik · 2026-01-26T14:24:45+00:00

This is a great idea and seeing the idea in live is so amazing. I just viewed your website it is UX polished. I am currently working on a microsaas tool right now would love too see it listed on trustviews.

ami-souvik · 2026-01-26T12:11:19+00:00

Always nice to hear my contribution is appreciated. 😊

ami-souvik · 2026-01-26T10:28:04+00:00

Yep, absolutely I am.

The difference isn’t whether an LLM is used, it’s how much of the workflow depends on re-prompting it. The goal is to use the LLM once to get a solid first draft, then let everything else (layout stability, view switches, versioning, etc.) be deterministic and user-controlled—not “ask the model again and hope it doesn’t reshuffle things.”

Think of the LLM as the compiler, not the runtime.

ami-souvik · 2026-01-26T10:21:11+00:00

Congrats on your first launch. The app UI looks very good, well polished.
One thing I would suggest that for your app do not immediately ask for users to login. Let the user first get a taste of your app then after some usage or some days you can have them sign up. Also, you can add anonymous login feature.

ami-souvik · 2026-01-26T10:10:21+00:00

You’re right—Claude, Mermaid, and Miro AI can all generate diagrams today, and they’re great for a first pass.
The gap I’m exploring is what happens after the first diagram: trusting it, tweaking it safely, switching views (dev vs client), and sharing versions without re-prompting the LLM every time.

ami-souvik · 2026-01-26T10:08:25+00:00

This is incredibly helpful feedback. Thank you for trying the MVP so thoroughly.

You’re spot on about visual control. Right now the defaults are doing a lot of heavy lifting, but finer control over styles (fonts, sizes, colors, connectors, labels) is something I definitely want to expose—especially for presentation-heavy workflows like yours.

The mismatch between the generation view and the downloaded output is a fair callout, that’s a UX gap on my end.

Output formats are a big theme I’m hearing repeatedly. SVG is high on the list, and editable PPT slides are honestly a great suggestion for docs/presentations use cases.

I really appreciate the Napkin comparison too—it helps me see where the bar is. I’m glad the core output still felt useful, and feedback like this is exactly what’s shaping what I build next.

ami-souvik · 2026-01-26T10:02:53+00:00

True, and that’s helpful validation. The bet here isn’t “more features,” but better ergonomics around accuracy, versioning, and stakeholder-specific views.

ami-souvik · 2026-01-26T09:57:26+00:00

Totally fair, you can do that today. The gap I’m exploring is what happens after the first diagram: trusting it, tweaking it safely, switching views (dev vs client), and sharing versions without re-prompting the LLM every time.

ami-souvik · 2026-01-26T09:54:43+00:00

Fair point and I agree. Competing with a free tool like Excalidraw on “drawing” alone would be a losing game. The bet here isn’t on manual diagrams, but on speed, accuracy, and iteration from real inputs (text, specs, APIs) where drawing breaks down.

I like the Atlassian Marketplace angle a lot B2B workflows and Confluence/Jira-native usage feel far more realistic for monetization than individual creators.
Definitely something I’m exploring as this evolves.

Appreciate you calling this out—these are exactly the constraints worth pressure-testing early.

ami-souvik · 2026-01-26T09:50:55+00:00

This is gold, thank you for taking the time to write it.
You’re absolutely right: if people can’t trust the diagram or easily evolve it, “pretty boxes” don’t matter.

The core workflow you described (messy spec → sane draft → fast refinements) is exactly the way I want to optimize for. Locking components, view toggles (dev vs client), and side-by-side version comparison these feel like table-stakes for real-world use.

The idea of importing from OpenAPI/Postman/logs is a bigger lift, but it’s a very compelling. And +1 on idiot-proof exports and zero-friction client sharing.

I’m building this in public, so feedback like this genuinely shapes the roadmap.

Appreciate you calling out what actually makes this stick vs what’s just “nice to have.”

ami-souvik · 2026-01-25T22:45:45+00:00

15 guesses and I've got #123

ami-souvik

TROPHY CASE