Different Ways of Sourcing Software Development Work — Open Source CXO Ep. 3 | Active Logic
In this episode, Matt Watson, Founder and CEO of FullScale.io, brings a perspective on software development sourcing that few guests can match. As someone who has built a company specifically designed to help organizations source development talent, and who has also built and sold technology companies of his own, Matt has seen the full spectrum of approaches — and the failure modes of each.
The conversation covers the fundamental question that every growing company faces: how do you get software built when you need it? The options range from building an internal engineering team to working with development agencies to hiring fractional CTOs to various outsourcing models. Each approach has trade-offs, and Matt is unusually direct about when each makes sense and when it doesn’t.
This episode is particularly relevant for non-technical founders, business leaders evaluating their technology sourcing strategy, and CTOs considering how to supplement their existing teams. Matt’s perspective is shaped by working with hundreds of companies across different stages and industries, which gives him pattern recognition that individual leaders — working within a single organizational context — often lack.
Key Insight: Internal Teams vs. Outsourcing — The Real Trade-offs
The internal-vs-outsourcing debate is often presented as a binary choice with one obviously correct answer. Matt rejects this framing. The right approach depends on what you’re building, your timeline, your budget, and your organizational maturity — and the answer may change over time.
Internal teams provide deep organizational knowledge, long-term commitment to the product, and the institutional memory that keeps complex systems maintainable. An engineer who has worked on your codebase for three years understands the architectural decisions, the business logic edge cases, and the technical debt in ways that no external team can replicate quickly. For core product development — the software development work that defines your competitive advantage — internal teams are almost always the right long-term investment.
But internal teams are expensive to build and slow to scale. Recruiting experienced engineers takes months. Onboarding them to a complex codebase takes additional months. And maintaining a large internal team requires management overhead, career development investment, and the fixed costs that come with full-time employment. For companies that need to move quickly, supplement existing capacity, or tackle specialized projects outside their team’s expertise, external sourcing provides flexibility that internal teams can’t match.
Matt’s framework: use internal teams for core product work and long-term strategic capabilities. Use external resources for capacity augmentation, specialized expertise you don’t need permanently, and time-sensitive projects where the recruiting timeline for internal hires would miss the market window. The key is being honest about which category your needs fall into rather than defaulting to a single approach for everything.
Key Insight: The Technical Expertise Challenge for Non-Technical Companies
One of the most significant challenges Matt sees across his clients: non-technical companies attempting to build software without adequate technical leadership. The results are predictably poor — and the companies often don’t recognize the problem until significant time and money have been invested.
The failure pattern: a company identifies a software need, hires developers (either internally or externally), and starts building. Without technical leadership who can evaluate architecture decisions, code quality, and development practices, the project proceeds on faith. The developers may be competent individually, but without someone who can make informed decisions about technology choices, system architecture, and development methodology, the result is often a system that works initially but becomes increasingly difficult to maintain, extend, and scale.
Matt describes the specific ways this manifests: technology stack choices driven by developer preference rather than business requirements, architectural decisions that create unnecessary complexity, insufficient attention to security and scalability, and accumulating technical debt that makes future development progressively slower and more expensive. For companies building web applications or mobile apps, these early architectural decisions have compounding consequences that are expensive to reverse.
His recommendation: if you don’t have internal technical leadership, invest in it before you invest in development capacity. Whether that means hiring a CTO, engaging a fractional CTO, or working with a development agency that provides technical leadership as part of their engagement, the cost of technical guidance is dramatically lower than the cost of building the wrong thing or building the right thing poorly.
Key Insight: Fractional CTOs and When They Make Sense
The fractional CTO model has gained significant traction, and Matt provides nuanced perspective on when it works and when it doesn’t.
A fractional CTO provides part-time technical leadership — typically helping with technology strategy, architecture decisions, vendor evaluation, and development team oversight. For companies that need technical leadership but can’t justify or afford a full-time executive, the fractional model provides access to experienced technology leadership at a fraction of the cost.
Where it works well: early-stage companies that need strategic technical guidance a few hours per week, companies evaluating major technology decisions (platform migrations, new product development, build-vs-buy), and organizations that need oversight of external development teams. In these contexts, a fractional CTO provides disproportionate value because the most impactful technical leadership activities — strategic decisions, architecture review, team assessment — don’t require full-time presence.
Where it struggles: situations requiring deep, continuous engagement with the codebase and team. A fractional CTO who is present two days a week misses context that accumulates during the other three. They can’t build the same relationships with the development team that a full-time leader builds. And their divided attention means they may not detect problems — performance issues, cultural dysfunction, accumulating technical debt — until those problems are significant. For organizations building complex systems involving AI, cloud infrastructure, or intricate business logic in ERP or CRM systems, the depth of engagement required often exceeds what a fractional model can provide.
Key Insight: Integrating Remote Developers Into Company Culture
Whether you’re hiring remote internal employees or working with external development teams, the cultural integration challenge is real and consequential. Matt describes the patterns he’s seen across hundreds of client engagements.
The most common failure: treating external or remote developers as purely transactional resources. Assign tasks, review outputs, repeat. This approach produces technically functional code but misses the organizational knowledge and product understanding that make the difference between software that works and software that serves the business well. Developers who understand the business context make better implementation decisions at every level — from variable naming to error handling to feature design.
Matt’s recommendation: integrate remote developers into your team’s communication channels, include them in relevant meetings, give them access to product roadmaps and customer feedback, and treat them as team members rather than vendors. The investment in integration pays for itself through better decisions, fewer misunderstandings, and reduced rework.
The practical challenges include time zone management, communication tool consistency, and access control. Remote developers — especially external ones — need enough access to be productive but not so much that security risks are unmanageable. Matt describes the balance: provide read access to relevant documentation and communication broadly, limit write access to systems and code repositories based on role, and establish clear data handling agreements before any engagement begins.
Key Insight: Data Security When Outsourcing Development
Data security is one of the most frequently cited concerns about outsourcing development work, and Matt addresses it with practical specificity rather than vague reassurance.
The legitimate concerns: external developers with access to your codebase, databases, and internal systems represent a security surface that internal-only teams don’t. Intellectual property exposure, data breach risk, and compliance implications (particularly in regulated industries) are real considerations that must be managed, not dismissed.
Matt’s framework for managing these risks: start with clear contractual protections including NDAs, intellectual property agreements, and data handling terms. Implement technical controls — access management, network segmentation, and activity logging — that limit exposure and provide audit trails. And conduct due diligence on any external development partner’s security practices before engagement begins.
The key insight: these risks exist with internal employees too. Insider threats, employee turnover with institutional knowledge, and the security implications of employee device management are all risks that organizations manage routinely for internal teams. The same risk management frameworks apply to external development resources — the threat model is similar, and the controls are largely the same. Organizations that refuse to outsource any development due to security concerns while simultaneously having inadequate security controls for their internal teams are addressing the wrong risk.
For organizations building portals or systems handling sensitive business data, the security framework should be consistent regardless of who writes the code. The controls that protect data from external developers also protect it from internal threats, departed employees, and the inevitable human errors that occur in any development organization.
Takeaways
- Match sourcing strategy to the type of work. Core product development belongs with internal teams; specialized or time-sensitive work may be better sourced externally.
- Invest in technical leadership before development capacity. Building software without informed technical guidance creates expensive problems that compound over time.
- Fractional CTOs work for strategic guidance, not deep operational engagement. Understand the limits of part-time technical leadership before relying on it.
- Integrate remote developers culturally, not just technically. Business context produces better implementation decisions at every level.
- Apply consistent security frameworks regardless of team composition. The controls that protect against external developer risks also protect against internal threats.
