How to Vet a Software Development Company: A Practical Guide | Active Logic Insights

I have been running Active Logic since 2014. In that time, I have had hundreds of conversations with companies who are either choosing their first software development partner or — more often — recovering from a bad experience with their last one.

The pattern is remarkably consistent. A company chooses a development partner based on a polished pitch and a competitive quote. Months later, they are stuck with a codebase that does not work, a team they cannot communicate with, and a budget that has doubled. They come to us asking to pick up the pieces.

This guide is what I wish those companies had read before signing that first contract.

Start With Who Is Actually Building Your Software

This is the single most important question, and most companies do not ask it directly enough: who will be writing the code?

Not who will be on the kickoff call. Not who will send you weekly status updates. Who will actually be architecting, developing, testing, and deploying your software?

Many development firms operate on a model I call “false-shoring.” They present a polished, domestic-facing team during the sales process — account managers, project managers, maybe a senior architect who shows up for the first meeting. Then the actual development work gets routed to offshore teams that the client has no visibility into. I wrote about this in detail in our false-shoring article — it is one of the most common and costly traps in the industry.

Questions to ask:

• Where are the developers who will work on my project located?
• Can I meet the actual development team before we start?
• What is the ratio of project managers to developers on a typical engagement?
• Are your developers full-time employees or contractors?

A high ratio of project managers to developers is a red flag. If there are three PMs and one developer, you are paying for coordination overhead, not engineering output.

Evaluate Technical Leadership, Not Just Sales

Every development company has someone who can give a great presentation. The question is whether that capability extends to the people making day-to-day technical decisions on your project.

Ask about technical leadership structure. Who provides architectural oversight? Who reviews code? Who makes the call when there is a trade-off between doing something fast and doing it right?

At Active Logic, every project is overseen by a Director of Engineering. These are senior technical leaders who have built complex systems across multiple industries. They provide architectural guidance, conduct code reviews, and ensure that decisions made in week two do not create problems in month six.

Not every company needs to structure their oversight the same way. But every company should be able to clearly articulate who is responsible for technical quality — and that person should not be the same person responsible for billing you.

Look at Actual Work, Not Just Logos

Portfolio pages and client logos tell you who a company has worked with. They do not tell you what they actually built, how it turned out, or whether the client would hire them again.

What to look for instead:

• Case studies with specifics. Not “we built a platform for Company X” but “we built a web application that processes 50,000 transactions daily with 99.9% uptime.” Specifics signal real experience.
• Technical depth. Can they talk about the architecture decisions they made and why? Can they explain trade-offs? A company that built something meaningful can discuss it in detail.
• References you can actually call. Ask for references from projects similar in size and complexity to yours. Then call them. Ask what went well, what did not, and whether they would hire the company again.

Use Third-Party Platforms — But Read Between the Lines

Platforms like Clutch, GoodFirms, LinkedIn, and GitHub can provide useful signal, but they require interpretation.

Clutch and GoodFirms: Look at the volume and recency of reviews. A company with 50 reviews from five years ago tells a different story than one with 20 reviews from the last two years. Read the actual review text — patterns in feedback (positive or negative) are more informative than aggregate scores.

LinkedIn: Look at the company’s actual team. Are the engineers listed on LinkedIn real people with real work histories? How long have they been at the company? High turnover on the engineering team is a warning sign — it often means the company cannot retain talent, which means your project will see rotating developers who need to ramp up repeatedly.

GitHub: If the company has public repositories, look at them. Code quality, documentation practices, and commit history tell you a lot about engineering culture. No public repos is not necessarily a red flag (much enterprise work is proprietary), but a strong public presence is a positive signal.

Understand the Engagement Model

How a company structures its engagements tells you a lot about how your project will actually run.

Fixed-price vs. time-and-materials: Fixed-price contracts sound appealing because they feel safe. In practice, they incentivize the wrong behavior — the vendor is motivated to do the minimum work necessary to meet the letter of the spec, and any change request becomes a negotiation. Time-and-materials with strong scope documentation and regular check-ins tends to produce better outcomes for custom software projects because it allows for the iteration that complex builds require.

Communication cadence: How often will you hear from the team? What does a typical status update look like? Will you have direct access to developers or only through a project manager filter? Direct developer access is not always necessary on every project, but it should be available when you need it.

Intellectual property: This should be straightforward — you should own the code. Read the contract carefully. Some companies retain IP rights or use licensing structures that create dependency. Your custom software should be yours, full stop.

Red Flags That Should Stop the Conversation

After a decade in this industry, these are the signals that consistently predict problems:

They cannot tell you who will work on your project. If the team composition is vague during the sales process, it will be worse during delivery.

The quote is dramatically lower than everyone else’s. Software development has real costs. Experienced U.S.-based engineers are not cheap. If a quote is 40% below the market, the question is not “how are they so efficient?” — it is “what am I not getting?”

They guarantee timelines before understanding requirements. Any company that tells you exactly how long a complex software project will take before doing thorough discovery is either lying or planning to hit you with change orders later.

They have no process for handling scope changes. Scope changes happen on every project. A mature partner has a transparent process for evaluating, communicating, and implementing changes. An immature one treats every change as either a crisis or a billing opportunity.

They push technology choices before understanding the problem. If the first conversation is about which framework to use rather than what business problem to solve, priorities are misaligned. Technology is a means to an end — the right stack depends on the problem, the constraints, and the long-term maintenance plan.

The Active Logic Approach

I will be transparent about how we work, because I think it illustrates what to look for in any partner.

Every engineer at Active Logic is a full-time, U.S.-based team member. We do not subcontract. We do not offshore. When you work with us, you know exactly who is building your software and where they are located.

Every engagement has a Director of Engineering providing technical oversight. We are structured around accountability — not layers of project management that create distance between the client and the people doing the work.

We work across custom software development, mobile apps, web applications, CRM and ERP systems, cloud infrastructure, and AI solutions. But we do not take on work outside our capabilities. If a project requires expertise we do not have, we will tell you.

Our approach is not the only valid one. But the principles — transparency, technical accountability, and honest communication — should be non-negotiable in any development partner you choose.

The Bottom Line

Vetting a software development company is not complicated, but it requires asking the right questions and being willing to dig past the sales pitch. Know who is building your software. Verify their work. Understand the engagement model. Watch for red flags.

The companies that do this well end up with partners who deliver. The ones that skip it end up calling companies like ours to fix what went wrong. I would rather you got it right the first time.