016: Collaborating with a software agency: a client’s guide

Hello and welcome to Speedtalks, podcast about everything tech in the financial services industry. I’m Michael, and today, we’re diving into a topic that comes up a lot in our conversations with clients. Especially at the beginning of a collaboration. And that is:

What do I need to know?

What do I need to know before starting a project with a software agency? Do I need to understand how code works? Do I need to be involved in every little detail? What should I bring to the table upfront? These are the kinds of questions we hear all the time, and they make a lot of sense. The beginning of any partnership can feel a bit foggy. You’re getting to know a new team, new processes, maybe even a new way of working. So it’s totally normal to feel unsure.

So in today’s episode, I want to clear some of that up. Or at least try to. We’ll look at what the early stages of working with a software agency actually involve – what you need to know, what you don’t, and where to focus your energy. Alright? Let’s dive in.

Do I need technical knowledge to lead an IT project?

This is probably the number one question we hear from new clients. And the short answer is: no, you don’t. The slightly longer answer? This is probably the number one question we hear from new clients. And the short answer is: no, you don’t. The slightly longer answer? While you’re not expected to be a technical expert (that’s the point of hiring a software agency), having a general understanding of how software projects work certainly helps. You don’t need to know Python from PHP or Angular from React, but it’s useful to understand the lifecycle of a project.

Consider these phases:

• What happens first?
• Who’s involved?
• When do key decisions get made?

Things like analysis, design, development, testing, launch – those are all pieces of the puzzle. And even if you’re not doing the coding yourself, your business decisions will affect the tech, and vice versa. So clear communication is crucial.

Collaborative process – what should you expect?

What do you need to know to collaborate effectively? I’d say: first and foremost – it’s not “just” about developers and code. Software projects are a full-on process. We’re talking UX/UI designers, business analysts, QA testers, product managers, etc. So here’s what makes a big difference right from the start.

• Have a clear idea of your business goals: what problem are you solving? Who’s it for?
• Keep communication open and regular: not just during kickoff, but throughout.
• Stay involved: especially when we’re gathering and clarifying requirements. That part’s key.

It’s a two-way street. The better we understand your needs, the better the end result will be.

What does the collaboration process actually look like?

It varies. Some agencies just focus on one part – like UX design, or just testing. But others, like us at Speednet, cover the whole thing. From the first idea all the way to long-term support. So here’s a general breakdown of what the journey might look like:

• Workshops & analysis: We define goals, outline scope, pick a tech stack, maybe sketch out wireframes.
• UX/UI design: Designers turn ideas into clickable prototypes and user-friendly interfaces.
• MVP & development: That’s where we start building. Lots of iteration, testing, adjusting.
• Testing & launch: We make sure everything works, and then… it’s go time.
• Maintenance & growth: Post-launch support, updates, new features, scaling.

Now, that might sound like a lot. But you’re not expected to be there every single day. That brings me to the next point.

How involved do I really need to be?

This one’s tricky — because we’ve seen both extremes. Some clients say: “Just call me when it’s live.” Others want to be in every daily stand-up. In my opinion, the best collaborations happen when there’s regular involvement – not micromanagement, but timely input when it matters. Think of it like checkpoints:

• Kick-off – We align on goals, budget, priorities.
• Workshops – You help clarify scope and user needs.
• Design & testing – Your feedback shapes the product.
• Business decisions – Like, what features matter most? Where should we invest first?

You don’t have to show up every day. But your voice matters, especially when it comes to product direction.

What do I need to bring to the table?

The smoother the start, the better the outcome. Here’s what’s super helpful upfront:

• A clear project goal – What are we solving? Who’s the user?
• A list of key features – What’s essential for version one?
• Any specific requirements – Are there legal constraints? Integrations?
• Your budget and timeline – even a rough range helps us guide you.

We’re not expecting a 100-page spec document. But the more clarity you can provide, the faster we can turn ideas into action.

There are also a few formal docs you might want to prepare or ask about:

• NDA – to keep your information safe
• DPA – if there’s any user data involved
• API docs – if we’re integrating with other systems
• SLA – for post-launch support expectations

How are requirements gathered?

Another good question. Because even if you don’t have a full spec, that’s totally fine. A lot of our clients start with a rough idea and we help them shape it through what we call discovery workshops. This typically involves:

• Functional & non-functional requirements
• Business goals
• User journeys — sometimes with UI prototypes or flow charts

By the end of that process, we’ve got enough to create a detailed scope and, more importantly, give a reliable time and cost estimate.

How much will it cost?

And now… the big question. It depends but we can certainly provide a ballpark:

• Small projects — from 19,000 to 190,000 złoty.
• Medium projects — from 190,000 to 770,000 złoty.
• Large enterprise systems — above 1.9 million złoty.

I talked a lot about costs in one of the previous episodes – check it here.

How long will it take?

As for timelines? Some projects go live in 3 months. Others take a year or more. That’s why early requirement gathering is so important – it lets us plan realistically.

Summary

• No – you do not need to be a tech expert.
• Yes – your involvement and clear communication matter.
• The more you bring to the table, the smoother the process.

Working with a software agency doesn’t have to be confusing or intimidating. It’s a collaboration and like any relationship, it works best when there’s trust, communication, and shared goals.

If you’re currently on the hunt for a tech partner, we’ve actually put together a short guide on how to choose the right IT partner in the financial sector. It’s got key questions to ask, red flags to avoid, all that good stuff.

That’s all for today. Thanks for hanging out with me, and I hope this helped clear up at least some of the mystery around working with a software agency. Catch you in the next episode. Bye for now!