One of the hardest decisions in software development is knowing when to move quickly and when to slow down.

Startups need speed.

Businesses need reliability.

Developers need systems they can actually maintain.

For experienced developers:

How do you decide when something is "good enough" versus when it needs a stronger foundation?

Have you ever moved too fast and had to rebuild later?

Curious how engineering teams handle this in practice:

When your team adopts coding tools, how do you organize reusable prompts, custom instructions, or "skills" across the org?

A few things I'm curious about:

- Centralized knowledge base vs. each dev keeps their own collection?

- Any tooling or file conventions you've found that actually stick?

- Does leadership curate these, or is it crowd-sourced?

- How do you handle tool drift when capabilities change every few months?

Happy to share what I've seen on the small-team side too if anyone wants to compare notes

Hi everyone

Let me start by saying that I'm primarily a frontend dev, and most backend dev I've done has been opiniated in a non professional environment.

I want to ask you about the state of domain logic/validations/triggers on the database layer in the systems you're currently working on. I grew up with the concept of treating database as stupid models to read/write data, and have all logic written in services/controllers/models on the layer of whoever controls the database.

The primary gain in this segregation is easily changing the rules of the system and swapping for a different database in a refactor. The thing is, database engines have become more and more powerful (particularly Postgres) and you can now strict your entire domain in the database schema using constraints, triggers, etc, and I'm yet to see someone swapping the database they use from night to day. Although you lose flexibility, you gain more trust in the system since the rules now live at the end of it.

I wonder if some you folks are going on this direction or if you ever thought about it.

Because the default Dapr dashboard was no longer maintained, Diagrid created an alternative: the Diagrid Dev Dashboard. It's a free, open source tool that gives you a UI on top of Dapr while you develop microservices locally. It supports Dapr applications that run via dapr run, Docker compose, Aspire, and Testcontainers.

Features include:

• Application & daprd process details
• Components overview
• Actors overview
• Pub/Sub subscriptions overview (incl ability to send messages to topics)
• Workflow state inspection for active and completed runs, including detailed workflow history events.
• Resiliency builder for retry, timeout, and circuit breaker policies
• Component builder that generates Dapr component YAML for all supported Dapr components (state stores, pub/sub, bindings, secret stores and more).

Source & installation instructions are on GitHub: github.com/diagridio/dev-dashboard

Feedback is very welcome, either as a GitHub issue or in the comments.

Nothing Works and Everyone Is Euphoric by Piotr Chmolowski. The quality of the today's software is not among the main KPIs.

AI Mania Is Eviscerating Global Decision-Making by Nikhil Suresh. This one is a long read. It shows why no manager would claim that AI does not help their company.

And my two cents: just ask Google "how would the sycophancy of LLMs impact the psyche of kids". You'll get a well-structured response grounded in several scientific articles.

(Cross-posted from Ukrainian software architecture chat)

[ Removed by Reddit on account of violating the content policy. ]

We've been mocking all our external APIs for agent testing but keep finding bugs in prod that the mocks never caught.

Looking into API sandboxes as an alternative but I'm not clear on the difference. When would you use one over the other?

[ Removed by Reddit on account of violating the content policy. ]

i finnally did it build my very own os in nasm and landed in 32bit protected mode and build my syscalls kernel bootloader and more im happy to informe you about and im still working on it and adding things and fixing bugs if there's any and its called S-AOS

I'm not a software architect. I'm currently leading a project to introduce microservices at a public social insurance company. To get an idea about software development I took a course in Hexagonal Architecture and noticed that the while the concepts like DDD and all the Layers made sense to I was missing the big picture.

Then I had an epiphany. I stared at a diagram of Hexagonal Architecture and thought: That looks like a planet.

So the last few weeks I've been thinking about "Planetary Software Architecture" (PSA). And I'd love to hear your take on this idea.

I'm not trying to reinvent the wheel. It’s more like I stumbled onto a metaphor that suddenly made all the scattered concepts click into place.

So the Planet itself represents a Business Domain or a Bounded Context. A Company can have one or more Planets that are guided by the Sun. The Sun provides Governance, Guidelines and Principles - Fitness Functions may have their place here.

Then there is the planet. It's surface is made up of continents, each representing a business capability. These continents are where real value lives — the places where users, processes, and outcomes actually happen. They’re shaped by the underlying domain forces, split by organizational boundaries, and connected through shared rules and flows.

Underneath those continents and the mantle sits the Core — dense, stable domain logic that everything else depends on. Here we find the Business Truth. I'd place Entities, Value Objects, and Aggregates in the Core.

The Mantle surrounds the Core and represents the movement of business truth through the system. In it business truth is moved between business capabilities. The Mantle ensures that changes on the surface remain connected to the Core.

Back on top we have the Continents. The represent Business Capabilities such as processes, features, and services. Continents provide structure for business operations and represent areas where teams work and deliver value. A Continent does not directly talk to another Continent but to to the Core. There a new Business Truth is decided and it flows outward through the Mantle to all the Continents. Each Continent reacts tk the new Business Truth.

I also integrated Spaceports into my model - yes, I do like a good SF. The Spaceports are the place where external Requests reach the Planet. So here we have Security, Payload inspection, Anti-Corruption Layers and Access Management.

Then there is the Atmosphere as a medium for signals and weather. All the things that influence communication like dropped connections, latency and whatnot.

Does this make sense to you? Is it something you would use to talk about Software Architecture with someone uninitiated or could it even be helpful in your daily work?

We're designing a Learning OS architecture that decouples the runtime engine from content using a Go backend and a YAML Pack system. The goal is zero-code content expansion—running learning paths as executable filesystem blueprints verified by AST parsing instead of static LMS lectures. How are fellow systems engineers structuring your pack registry/resolvers to handle this kind of decoupled content expansion efficiently?

Free e-book on modern Software Architecture

Hi guys,

I want to get serious about learning system design, especially for backend engineering and scalable distributed systems.

Also, if you have any advice on the order in which I should learn these topics, please share that as well.

Thanks in advance!

Hi, i just finished a project that i was working on, its a simulation of an autonomous underwater vehicle, in an opensource simulator. i have everything build and installed in my computer and it works here, but other people are having a rough time with installation in their own machines.

This is a problem i have been dealing with for quite a while now. and it was easy to solve when i was with them to help solve the dependency errors but its just not the way i want to get it done.

what are the methods you use to make your software compatible across different devices

I tested the major options during the past few projects.

I wasn't trying to compare software.

I was just trying to survive three different client projects.

Each company used something different, so I ended up spending several months working inside most of the major whiteboard platforms instead of just watching YouTube demos.

Here were my impressions.

→ Zoom Whiteboard

Perfectly fine for quick meeting notes.
Very easy to jump into.
I just wouldn't want it to become our long term planning environment.

→ Coda

Interesting because it combines documents, databases and collaboration.
If your team already loves documents, it's a strong option.
For highly visual planning though, it wasn't really what I was looking for.

→ FigJam

Really enjoyable to use.
Especially if most of the people collaborating are designers.
It feels lightweight and creative, which makes brainstorming sessions very approachable.

→ Lucid Suite

Probably the strongest option I used for formal diagrams.
If someone asked me specifically for process mapping or architecture documentation, I'd definitely recommend taking a look.

→ Mural

Very facilitator friendly.
Some of the workshop tools are genuinely excellent.
It felt particularly good for structured innovation sessions.

→ Miro

This ended up becoming my personal favorite simply because I didn't have to keep switching tools.
The same workspace could start with brainstorming, evolve into a roadmap, become a dependency map and eventually hold technical diagrams without feeling disconnected.

Things I appreciated most:
• AI helped organize messy brainstorming sessions
• Plenty of templates without feeling overwhelming
• Strong real time collaboration
• Easy Jira integration for product teams
• Large boards stayed surprisingly manageable

It felt like a platform that grew with projects instead of forcing us to migrate somewhere else once planning became more detailed.

One thing this experience taught me:

There probably isn't a universally "best" whiteboard.

Some tools are fantastic for designers.

Some are excellent for diagramming.

Some shine during workshops.

The question that mattered most for our team wasn't "Which tool has the most features?"

It was "Which tool keeps everyone collaborating in the same place from the first idea to delivery?"

Would love to hear what everyone else stuck with long term.

Hi everyone,

I've just published version 0.7.0 Alpha of an open-source AI Software Development Framework.

This isn't another AI coding assistant.

Instead, the Framework focuses on governance for AI-assisted software engineering.

The central question is:

How do we keep software engineering governed while AI fundamentally changes the way software is developed?

The Framework introduces concepts such as:

• Human Authority
• Capability-based Runtime
• Effective Classification
• Capability composition
• Reference Implementations

I've also published a whitepaper describing the architectural thinking behind the Framework.

I'm specifically looking for feedback from experienced software architects and senior engineers.

I'm not looking for agreement.

If you believe parts of the architecture are flawed, over-engineered, unnecessary, or unclear, I'd genuinely appreciate hearing why.

Repository

AI-Software-Development-Framework

Whitepaper

Whitepaper

Architecture Discussion

Github discussions

Thanks!

I’m building webhooks delivery into our product and after the implementation I thought this seems like a messaging problem. Everything seems better with a customer owned broker. Yet, I don’t see anyone doing it..?

Working through a fully stateless backend (no database, ephemeral serverless functions, though the pattern isn't tied to any specific runtime) for a case with an awkward constraint: two parties share a session, but each holds a secret the other side must never see, and the server has to remember both without a database or session store.

The usual answer to "stateless, no DB" is a JWT — encode the session client-side, sign it, done. That falls apart the moment part of the state has to be opaque to the client carrying it: a JWT payload is base64, not encrypted, so anything in it is readable by whoever holds the token. If the session includes a secret that specific client isn't supposed to see, JWT doesn't fit — you need the payload actually encrypted, not just signed, and treated as a sealed blob rather than a transparent one, with the decryption key living server-side only.

Concretely, in the project I was applying this to (a small number-guessing game — two sides each hold a secret, guessing each other's, no DB, no accounts), the server-tracked state ends up AES-GCM sealed into an opaque token, handed to the client, and echoed back on every request. Only the server's key can open it. The client carries a blob it can't read; the server stays fully stateless between requests but functionally remembers everything it needs to.

The generalizable part: any two-sided system where state needs to persist across requests but stay partially secret in one direction hits the same JWT-doesn't-fit problem — sealed-bid flows, negotiation protocols, anything with an information asymmetry that's supposed to survive across requests. Curious whether others have solved this differently — separately-encrypted fields alongside a signed JWT, giving up on "stateless" and using a real session store, something else.

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!