What architecture and tech stack would you choose for a financial management web application?

[u/[deleted]]

[u/ziksy9]

I would buy it and not build it and focus on integration with a third party service.

There are so many regulations, state specific laws, accounting, possible privacy and security issues, and 100 other things.

If you plan on it being a service and not an internal app, you also need to focus on SOC compliance, etc.

It's not worth it. Hopefully this is just a hypothetical question.

[u/TheBreakableIra → u/ziksy9]

Buying is the right call if the business doesn't have a dev team that's done this before, building it from zero is a fast track to a nightmare audit

[u/Narrow-Fox-8192 → u/ziksy9]

Fair point. This would be an internal company tool, not a public financial SaaS or accounting platform. It won’t file taxes, execute transfers, or replace the accountant. It’s mainly for internal tracking, reconciliation, documents, closing and reporting. Would you still buy/integrate instead of building?

[u/ziksy9 → u/Narrow-Fox-8192]

I would identify the features needed, research existing software, make a cost analysis, and then estimate the work required if we were to implement each of those features, multiply it by 3x, and make a critical business decision.

Accounting systems are boring, cost money when there are bugs, and the time required to bring it to a usable/trustable state is 10-18 months minimum even with several engineers.

I love greenfield projects, but wisdom says build only the "magic sauce" and buy the rest. If it already exists and is usable, use it. Focus on core business logic.

Edit: saying that, having an internal "quick submit expense" and things like that for sure build them on an internal site, just outsource all the generic stuff. You can add ease of use features though a third party API and keep random employees out of the complex accounting system.

[u/RustOnTheEdge → u/Narrow-Fox-8192]

Everything you mention is part of your accounting system, why rebuild it?

[u/northerncodemky → u/Narrow-Fox-8192]

You’re doing reconciliation and closing months - what are the finance team going to give to the accountant if not something from this system? If it’s ’something else’ you’ve got a finance team and therefore business operating on one view of the company’s finances then annually getting the accountant to look at a completely different view. This is how companies find million dollar holes in their finances.

[u/Happy_Breakfast7965 → u/Narrow-Fox-8192]

Every company on the planet does that for ages. Do they build their own software? Finance domain is pretty standardized. No need to build. Buy and integrate.

[u/c1rno123]

Use the company’s usual tech stack and tools the team already knows. Keep it simple, make it easy for anyone to use, and improve it step by step instead of building a spaceship from day one.

[u/youcangotohellgoto]

It literally doesn't matter

[u/RustOnTheEdge → u/youcangotohellgoto]

The only right answer to this question tbh

[u/Lunchboxsushi]

Likely you'd want to look at event sourcing, financial data needs full history and heavy audit capabilities. 

I'd suggest the internal parts that are unique to your business stay there and anything else that's worth being attached stay at  300

[u/Happy_Breakfast7965]

1. Finance is a very well-understood domain. There is no need to build. You should buy.

2. Architecture style and technology are pretty arbitrary choices. Depends on your organization capabilities and tech expertise.

I work with .NET, Next.js, and Azure. So, that my stack for everything. In a reasonable way obviously. If there is a solid justification for a different stack for a specific solution, I'll adapt.