💬 Interview: Daniel on Solution Architecture

Building an app is like building a house – you need an architect before you start laying bricks. At Devika, that role is handled by Daniel, our Solution Architect. We sat down with him to explore what non-technical founders really need to understand before jumping into development, and how to avoid costly mistakes down the road.

1. Let’s start simple: what is solution architecture?

Daniel:

Solution architecture is the high-level planning of how an app or feature will work. It’s about making the right decisions before you write any code. We start by understanding the business case and what needs to be built. Then we look at similar builds we’ve done before, do extra research if needed, and design the overall cloud architecture. From there, we break it down into individual components.

2. What are the biggest mistakes you see founders make early?

Daniel:

There are three key decisions that are hard to undo: language, database, and infrastructure. If you choose the wrong one, you may need to rewrite everything later. A bad database choice, for example, can also lead to high ongoing costs. These are decisions founders shouldn’t try to make on their own – it’s better to lean into experts.

3. What about founders who just want to build something fast?

Daniel:

Building fast can work, if done properly. With Baseline, we can move quickly without making bad long-term decisions. It’s built using serverless architecture, which means you don’t pay much when you have no users, but it can scale automatically when you grow. You can move fast without locking yourself into something you’ll regret.

4. **If someone has a small budget, what should they not cut corners on?**

Daniel:

Don’t try to build your own authentication or hosting – just use something that’s already secure and proven. Also, really think about whether you need a mobile app from day one. A mobile-responsive web app might be enough early on. And unless AI is core to your product, you can skip it at the MVP stage. It’s an enhancement, not a foundation.

5. What should a non-technical founder understand about their tech stack?

Daniel:

You don’t need to know every detail, but you should understand cost and scalability. Developer-only costs for an MVP should be under $100/month. If it’s more than that, it’s going to blow out as you grow. Also, make sure your app is hosted on a major cloud provider like AWS or Azure. Avoid random platforms that lock you in or make it harder to scale. And early on, skip microservices; they’re expensive and unnecessary for small apps.

6. What are some red flags when reviewing an MVP that’s already been built?

Daniel:

Hosting is a big one. If it’s on an obscure or hard-to-maintain platform, that’s usually a problem. Also, if it’s built mostly by stitching together third-party tools with very little actual code, that can create major issues later. And if it’s overengineered – like using microservices or containers for something simple – that’s a sign the build wasn’t aligned with the actual needs.

7. How does a founder make sure they actually own their tech?

Daniel:

Make sure it’s hosted on a mainstream platform and that you have access to the code and backend – even if you’re not using it right away. You don’t need to manage it yourself, but you should always have the ability to take it elsewhere if needed.

8. What makes Devika different in how we approach building apps?

Daniel:

We’re always close to the bleeding edge. Part of my role is to stay across new tools and technologies, and we introduce improvements gradually across projects so the team isn’t disrupted. Every new project gives us a chance to try something better, without reinventing everything. That’s how we stay innovative while delivering consistently and efficiently.

Whether you’re building for scale or just getting your idea off the ground, the right architectural decisions upfront will save time, money, and stress later. At Devika, we’re here to help you make them.

Reach out for more information.