Last September, David, the COO of a 60-person fintech startup in West LA, signed a $180,000 contract with a software development company he found through a Google search. The portfolio looked great. The proposal was detailed. The team seemed sharp on the discovery call.
Four months later, the project was 60% over budget, three months behind schedule, and the lead developer had been quietly swapped out for a junior contractor in a different time zone. David’s team had spent more time managing the vendor than building their own product.
They ended the engagement, ate the loss, and started over.
David’s story isn’t unusual. It’s the story that makes business owners hesitant to invest in custom software over off-the-shelf tools at all, and it’s almost always preventable.
If you’re evaluating software development companies, especially in a market like Los Angeles where the options range from solo freelancers to 500-person agencies, the difference between a good engagement and a disaster usually comes down to the same handful of checkpoints.
This guide walks through each one so you can vet vendors the way someone who’s been burned would, without having to get burned first.
Here’s what we’ll cover:
| Section | What You’ll Learn |
|---|---|
| The pre-search homework | What to have ready before you talk to anyone |
| Portfolio red flags | What to look for (and what to ignore) |
| The right questions | 12 questions that separate good vendors from great ones |
| Pricing models | Fixed-price vs. T&M and when each makes sense |
| LA-specific factors | Why geography still matters for software projects |
| The contract checklist | What your agreement should include before you sign |
Before You Talk to Anyone: Do Your Homework First
Most people start their search by Googling “software development company Los Angeles” and clicking through portfolios. That’s step five in how to choose a software development company. Here’s what should come before it.
Define the problem, not the solution. “We need a mobile app” is a solution. “Our field service team wastes 3 hours a day on paper forms and can’t access client history on-site” is a problem. Good development companies can propose solutions you haven’t thought of, but only if you describe the problem clearly. If you haven’t yet, validate that you actually need custom software first before you start vendor conversations at all.
Set a realistic budget range. You don’t need an exact number, but you need a range. If you’ve never built software before, our breakdown of custom software development costs gives you the context to set reasonable expectations. Going into conversations with no budget is like house-hunting with no price range. You’ll waste everyone’s time, including yours. And if you’re still gut-checking the “do we even need this?” question, the five signs that signaled it was time for custom software is a short read worth doing first.
List your must-haves vs. nice-to-haves. Write two columns. The left column is what the software absolutely must do on day one. The right column is everything else. A good vendor will use this to scope an MVP or phased delivery — see realistic MVP budget ranges by product type for what that first phase should actually cost. A bad vendor will quote you the full wish list and let scope creep handle the rest.
Know your timeline constraints. “As soon as possible” isn’t a timeline. “We need to demo this to investors on March 15” is. If there’s a hard deadline, say so up front. It changes everything about how a project should be scoped and staffed.
What a Portfolio Actually Tells You (And What It Doesn’t)
Everyone looks at portfolios. Directories like Clutch make it easy to browse hundreds of software development companies in Los Angeles alone. Few people look at them correctly.
What to actually evaluate:
- Relevance to your industry or problem type. A company that’s built three fintech platforms understands compliance requirements you won’t have to explain. A company that’s only built e-commerce sites might not.
- Technical depth in the case study. “We built a beautiful app” tells you nothing. “We migrated 2.3 million records from a legacy Oracle database to PostgreSQL with zero downtime” tells you a lot.
- The client’s size and stage. If every project in their portfolio is for Fortune 500 companies, and you’re a 20-person startup, you’re probably not the right fit. And vice versa.
What to ignore:
- Visual polish of the portfolio itself. Some of the best development shops have mediocre websites. Some of the worst have stunning ones. The portfolio site tells you about their marketing budget, not their engineering ability.
- Number of projects listed. Quality matters more than quantity. Five detailed case studies beat fifty logos.
- Technology badges. “AWS Partner” and “Google Cloud Certified” are marketing signals, not quality guarantees. They mean someone on the team passed a certification exam.
When Priya, the VP of product at a healthtech company in Culver City, was evaluating vendors last year, she almost passed on a small studio because their website looked dated. Then she noticed their case studies included three healthcare projects with HIPAA compliance details, architecture diagrams, and specific performance metrics.
She called them. They turned out to be the strongest technical team in her shortlist by a wide margin.
The lesson: read the case studies, not the design.
12 Questions to Ask a Software Development Company
You’ll get basic information from any vendor’s website. These twelve questions surface the information that actually predicts project success, and they’re the most reliable way to vet a software development company before signing anything.
About Their Team
1. “Who will actually write the code on my project?” This is the single most important question. Many agencies sell with senior engineers on the call and staff with juniors after the contract is signed. Ask for names and LinkedIn profiles of the people who’ll be assigned. If they can’t tell you, that’s a red flag.
2. “Do you subcontract or offshore any of the work?” Not inherently bad, but you need to know. If the answer is “sometimes,” ask exactly what gets subcontracted and what stays in-house. The worst projects happen when a client thinks they’re working with a local team and discovers halfway through that the actual developers are three time zones away.
3. “What happens if my lead developer leaves mid-project?” Every company has turnover. Good ones have a plan for it: documentation practices, code review processes, knowledge sharing. If the answer is “that won’t happen,” they haven’t thought about it.
About Their Process
4. “Walk me through what happens between signing the contract and writing the first line of code.” You’re looking for a discovery or scoping phase. If they jump straight from contract to coding, they’re building without a blueprint. Every solid custom software engagement starts with a written specification before development begins. See what a healthy seven-phase development process looks like to benchmark what your vendor should describe when you ask them to walk you through it.
5. “How often will I see working software?” The answer should be measured in weeks, not months. Bi-weekly demos of working features is the industry standard for a reason. If they deliver one big reveal at the end, you have no ability to course-correct along the way.
6. “How do you handle scope changes after the project starts?” Scope changes are inevitable. Good vendors have a change order process: you describe the change, they estimate the impact on timeline and budget, you approve or defer. Bad vendors either say “no changes allowed” (rigid) or “sure, we’ll figure it out” (scope creep incoming).
About Their Track Record
7. “Can I talk to a client whose project went sideways?” Any vendor can give you a happy reference. Asking about a difficult project and how they handled it tells you far more. Did they communicate proactively? Did they eat the cost of their own mistakes? Did the client relationship survive?
8. “What’s the most common reason projects fail, in your experience?” You’re looking for self-awareness. If they say “bad clients,” walk away. If they say something specific like “unclear requirements” or “trying to build too much in v1,” they’ve learned from experience.
About Ownership and After
9. “Who owns the code after the project is done?” The only acceptable answer is “you do.” Full intellectual property transfer. No licensing, no ongoing fees to use what you paid for. If they retain ownership or require a license, you’re renting, not buying. Check the contract language carefully.
10. “What does your warranty period look like?” Good vendors offer 30-90 days of bug fixes after delivery. If they don’t mention a warranty, ask why. Software always has bugs at launch. The question is who fixes them and at what cost.
11. “What do I need to maintain this after you’re done?” You need documentation, deployment procedures, and enough knowledge transfer that another developer (or your own future hire) can pick up the codebase. If they say “you’ll always need us,” that’s vendor lock-in by design.
12. “Can you show me your standard contract?” Review it before the final proposal. Look for IP ownership clauses, payment milestones tied to deliverables (not just dates), warranty terms, and termination conditions. If they resist sharing the contract template early, ask yourself why.
Want to see how a transparent development company operates? Learn about our approach or schedule a call to ask these questions directly.
Pricing Models: Fixed-Price vs. Time and Materials
Understanding pricing is critical when you hire a software development company. There are two standard models. Neither is inherently better. The right one depends on how well-defined your requirements are.
Fixed-price means you agree on scope, timeline, and cost up front. You pay a set amount for a defined set of deliverables.
- Best for: Projects with clear, well-documented requirements. MVPs. V1 products where the feature set is locked.
- Risk: If the scope was poorly defined, the vendor will either cut corners to stay on budget or come back with change orders.
- What to watch: Make sure the fixed price is tied to a detailed scope document, not a vague proposal. “Build a web application” is not a fixed scope. “Build a web application with these 14 screens, these 6 API integrations, and this authentication flow” is.
Time and materials (T&M) means you pay for hours worked, usually at a weekly or monthly rate.
- Best for: Exploratory projects, ongoing development, projects where requirements will evolve significantly.
- Risk: No cost ceiling unless you set one. T&M without a budget cap is a blank check.
- What to watch: Insist on weekly hour reports and a not-to-exceed clause. Good T&M vendors will proactively flag when you’re approaching budget limits.
When Jason, the founder of a logistics SaaS in Long Beach, hired his first development team, he chose the cheapest hourly rate he could find: $45/hour from an offshore shop. The project was quoted at 400 hours.
It took 1,100 hours and the final product needed a complete rebuild. The “$18,000 project” cost $49,500 and produced software that never shipped.
His second attempt was a fixed-price engagement with a local studio at $140/hour. The project cost $84,000, delivered in 10 weeks, and has been running in production for two years. The hourly rate was three times higher. The project cost was 70% less in real terms.
The takeaway: hourly rate is not project cost. A $45/hour developer who takes three times as long is more expensive than a $140/hour developer who gets it right the first time. Compare total project cost, not hourly rate.
For a deeper comparison of pricing approaches, see our guide to custom software development costs.
Why Los Angeles (and Geography Still Matters)
Remote work has made it possible to hire developers anywhere. But for custom software projects, especially your first one, geography still carries real advantages.
Same time zone, same business hours. When something breaks at 2 PM Pacific, you want your development team available, not asleep. When you have a question during a Thursday standup, you want a real-time conversation, not a Slack message that gets answered 12 hours later.
Face-to-face when it matters. The discovery phase, the midpoint review, the final handoff. These milestones go better in person. A 30-minute drive to an office in Santa Monica or downtown LA is worth more than a perfectly organized Zoom call for the conversations that define a project’s direction.
Understanding the local market. An LA-based development company understands the industries that drive this market: entertainment, logistics, real estate, healthcare, e-commerce, and the startup ecosystem along Silicon Beach. They’ve probably built for companies like yours before.
That context saves weeks of explanation and prevents architecture decisions that look fine on paper but don’t fit the reality of your industry.
Accountability. A local company has a local reputation. They show up at the same meetups, know the same people, and can’t disappear into a different jurisdiction if things go wrong. That’s not a guarantee of quality, but it’s a meaningful constraint on bad behavior.
This doesn’t mean you should never hire remotely. If you’ve built software before and know exactly what you need, a remote team can work well.
But if this is your first custom project and you’re not sure what questions to ask yet, working with someone you can sit across a table from reduces the risk considerably.
The Contract Checklist: What to Verify Before You Sign
You’ve done your research, asked the right questions, and picked a vendor. Before you sign, verify these seven items in the contract:
1. IP ownership clause. The contract must explicitly state that all intellectual property, including source code, documentation, and design files, transfers to you upon final payment. No exceptions. No shared ownership. No licensing.
2. Payment tied to milestones, not dates. You should pay when deliverables are completed and accepted, not on arbitrary calendar dates. A typical structure: 20% at signing, then equal payments at 3-4 milestones, with final payment at delivery and acceptance.
3. Defined acceptance criteria. How do you formally accept or reject a deliverable? There should be a review period (typically 5-10 business days) and a clear process for requesting revisions.
4. Change order process. Documented process for handling scope changes. New features or changes should require a written estimate of cost and timeline impact before work begins.
5. Warranty period. 30-90 days of bug fixes after final delivery, at no additional cost. Bugs are defects in the delivered software against the agreed specification, not new feature requests.
6. Termination clause. What happens if the project needs to end early? You should receive all work completed to date, including source code, for a prorated payment. Avoid contracts that hold code hostage.
7. Confidentiality. Mutual NDA covering your business information, user data, and proprietary processes. Standard practice for any professional engagement.
If any of these are missing from the contract, ask for them. If the vendor pushes back on IP ownership or refuses to tie payments to deliverables, that tells you something important about how the engagement will go.
The U. S. Small Business Administration’s guide to hiring contractors covers additional legal considerations worth reviewing.
Red Flags That Should End the Conversation
Knowing what to look for in a software development company is half the battle. The other half is knowing when to walk away. Here are the signals:
- They can’t tell you who will work on your project. If staffing is a mystery before the contract, it will be a problem after.
- They don’t have a discovery or scoping phase. Going straight from “nice to meet you” to “here’s the invoice” means they’re building without understanding.
- They won’t share references. Every legitimate company has at least two clients willing to vouch for them.
- They quote a price before understanding the scope. A number without a scope is a guess. Guesses favor the side that made them.
- Their proposal is a template with your name filled in. You can tell. If they didn’t customize the proposal, they won’t customize the software.
- They promise everything and push back on nothing. Good vendors say “no” when a request doesn’t make sense. If they agree to everything, they’re either not listening or not planning to deliver.
- They retain IP ownership. You’re paying them to build it. You should own it. Full stop.
- They disappeared from the portfolio. If you can’t find recent work, ask why. Companies that stop shipping are companies with internal problems.
The Decision Framework
After you’ve talked to three to five vendors (don’t talk to more than that, diminishing returns set in quickly), score them on these five criteria. If you’re still deciding between a freelancer, agency, or in-house team, start there first.
| Criteria | Weight | What You’re Evaluating |
|---|---|---|
| Technical fit | 25% | Can they build what you need? Have they built similar things? |
| Communication quality | 25% | Were they responsive, clear, and proactive during the sales process? |
| Process maturity | 20% | Do they have a defined workflow from discovery through delivery? |
| Team transparency | 15% | Do you know exactly who will work on your project? |
| Pricing clarity | 15% | Is the cost structure clear, with no hidden fees or ambiguous terms? |
Communication quality is weighted equal to technical fit for a reason. The most talented developers in the world can’t save a project where the client and the vendor aren’t talking clearly. The sales process is a preview of the working relationship. If communication is difficult before money changes hands, it won’t improve after.
How to Choose a Software Development Company: The Short Version
Choosing a software development company is one of the highest-stakes vendor decisions a business makes. The wrong choice costs six figures and months of lost time. The right choice produces software that compounds value for years.
The good news: the due diligence process is straightforward. Define your problem clearly. Ask the twelve questions above. Verify the contract checklist. Trust the vendor who tells you hard truths over the one who tells you what you want to hear.
If you’re evaluating development companies in Los Angeles and want a conversation with a team that will tell you honestly whether your project is a good fit for custom development, schedule a free 30-minute call. Bring your requirements list. We’ll give you a straight answer, even if the answer is “you don’t need us.”