Why Do Many Companies End Up With Unusable Software?
Nobody wants to spend hundreds of thousands of baht on a program nobody uses — or a system full of bugs that needs endless fixing after go-live.
Yet dozens of projects across Thailand end this way every year. The root cause usually isn't that developers aren't skilled. It's that the project started wrong.
This article helps you start right from day one.
Understanding the Role of a Software House
A software house is a company that develops software to client specifications (Custom Software Development). This is different from:
- Product company — Builds their own software products to sell to many customers (e.g., SAP, Freshworks)
- IT consultant — Provides advice, doesn't necessarily build anything
- System integrator — Specializes in connecting existing systems together
A good software house has a complete team: Business Analyst, UX Designer, Frontend Developer, Backend Developer, DevOps, QA Tester, Project Manager
Freelancer vs Software House — Which to Choose?
| Factor | Freelancer | Software House |
|---|---|---|
| Cost | Lower | Higher, but more complete |
| Accountability | Individual (high risk if they disappear) | Company (contractual) |
| Team | One person or network | Complete PM, Dev, QA team |
| Process | Depends on the individual | Standard Agile/Scrum process |
| Post-launch support | Uncertain | Defined SLA |
| Best for | Small projects, clear scope | Mid to large projects, long-term |
For company software: A software house is a better fit because you need long-term support and the risk of project failure is significantly lower.
5 Questions to Ask a Software House Before Signing
Question 1: "Who exactly will be working on my project?"
You need to know who the PM is, who the Lead Developer is, whether the team has done similar projects, and whether they're dedicated to your project or juggling multiple at once.
Question 2: "Can you show me past work?"
Ask to see a portfolio or case study similar to what you need. Request references from past clients to call and ask about their experience firsthand.
Question 3: "Walk me through your process."
A good software house should clearly explain their process: Discovery → Design → Development Sprints → UAT → Go-Live → Support. A well-defined process dramatically reduces risk.
Question 4: "Who owns the source code after go-live?"
This is critical. You must own the source code once you've paid in full. Verify this clearly in the contract. Otherwise, switching software houses in the future becomes a major problem.
Question 5: "What does your warranty and post-launch support look like?"
There should be a free bug fix warranty period (industry standard is 3–6 months), and a defined support plan afterward — either retainer-based or pay-per-ticket.
Documents to Prepare Before Briefing a Software House
Preparing these in advance leads to more accurate quotes and less miscommunication:
1. Business Overview Document
- What does your company do? Who are your customers?
- The current problem you need to solve
2. Current Process Documentation
- How your current workflow operates (even manual is fine)
- Screenshots of existing systems
3. Feature Wishlist
- What the new system must do, categorized as Must Have / Nice to Have
- What the system doesn't need to do (helps narrow scope)
4. Technical Information
- Existing systems that need integration, with API documentation if available
- Target platform (Web / iOS / Android)
5. Rough Budget and Timeline
- Budget range you can work with
- Hard deadline if there is one
Red Flags — Warning Signs to Watch For
🚨 Red Flag 1: Gives you a price immediately without asking anything
Good software requires understanding requirements first. A price within 10 minutes of receiving a brief is meaningless — and often leads to scope creep later.
🚨 Red Flag 2: No BA or PM on the team
If the team is all developers with no Business Analyst or Project Manager, expect communication problems and missed requirements throughout the project.
🚨 Red Flag 3: Won't let you see progress along the way
A good software house should demo every sprint (every 2 weeks). If you can't get visibility into progress when you ask, that's a serious warning sign.
🚨 Red Flag 4: Contract doesn't specify source code ownership
Read the contract carefully. If it doesn't clearly state that source code is your IP after full payment — clarify before signing.
🚨 Red Flag 5: Portfolio has no detail or can't provide client references
Ask for references to call directly. If they can't provide any, that's a concern.
Expected Timeline
| Phase | Activity | Duration |
|---|---|---|
| Pre-Sales | RFP, Demo, Quotation | 1–2 weeks |
| Contract | Review and sign | 1 week |
| Discovery & BA | Workshops, requirement finalization | 2–4 weeks |
| Design & Prototype | Wireframe, UI design | 2–3 weeks |
| Development | Agile sprints | 8–24 weeks |
| UAT | Client testing | 1–3 weeks |
| Go-Live | Deployment, training | 1 week |
| Support | Post-launch | Ongoing |
Summary
Hiring the right software house for your company program requires:
- Prepare clear requirements — The clearer they are, the more accurate the quote
- Ask the right questions — Team, portfolio, process, IP ownership, support
- Watch for red flags — Suspiciously fast quotes, no BA/PM, no demos allowed
- Review the contract before signing — Must specify source code ownership and warranty
- Plan to stay involved — Successful projects require your active participation throughout
Want advice on how to start your software project the right way?
The Adowbig team is happy to provide free guidance. Contact us today