DEV Community: Khalfan

How Investors Evaluate Technical Leadership Before Funding a Startup

Khalfan — Thu, 09 Jul 2026 12:53:43 +0000

When founders prepare for fundraising, they often focus on revenue growth, market opportunity, customer traction, and financial projections. While these factors are important, investors also pay close attention to something that many startups overlook: technical leadership.

For technology-driven companies, the ability to build, maintain, and scale a product can significantly influence investment decisions. Investors want confidence that the startup's technology can support future growth without creating unnecessary risk.

This is one reason many founders eventually consider whether they need to hire a CTO as the company matures and fundraising becomes a priority.

Why Technology Matters to Investors

Investors are not simply funding a product. They are funding a company's ability to execute over the long term.

A startup may have a strong idea and early traction, but if the technology foundation is weak, growth can become difficult to sustain.

Investors often evaluate:

Product scalability
Engineering capabilities
Development processes
Security practices
Technical risks
Leadership quality

The goal is to determine whether the company can continue growing without major technical obstacles.

Technology Risk Is Business Risk

From an investor's perspective, technical problems can quickly become business problems.

For example:

Poor system architecture can slow growth.
Security vulnerabilities can damage customer trust.
Development bottlenecks can delay product releases.
Infrastructure limitations can increase operating costs.

Investors understand that technology affects revenue, customer retention, and operational efficiency.

As a result, they often spend considerable time evaluating how technical decisions are made within the company.

Questions Investors Commonly Ask

Technical due diligence varies depending on the size of the investment, but several questions appear consistently.

Who Owns Technology Decisions?

Investors want to know who is responsible for technical strategy.

If no clear ownership exists, it may indicate future management challenges.

They often look for someone who can confidently explain:

Technology choices
Product architecture
Development priorities
Scalability plans

Clear accountability increases investor confidence.

How Is the Product Built?

Investors frequently examine the structure of the product itself.

Areas of interest may include:

Architecture quality
Infrastructure design
Documentation standards
Development workflows

They are not necessarily looking for perfection. Instead, they want evidence of thoughtful decision-making.

Can the Product Scale?

Scalability is a major concern, especially for software businesses.

Investors want to understand:

How systems will handle growth
Whether infrastructure can support future demand
What challenges may emerge at larger scale

A startup that has considered these questions often appears more prepared for expansion.

The Leadership Factor

Technology alone is rarely enough to secure investment.

Investors also evaluate the people responsible for building and maintaining it.

Strong technical leadership demonstrates that the company can:

Adapt to challenges
Make informed decisions
Recruit talented engineers
Execute complex projects

Leadership quality often matters as much as technical expertise.

Investors frequently place significant value on teams that combine business vision with technical competence.

Common Red Flags During Technical Due Diligence

There are several warning signs that can reduce investor confidence.

No Clear Technology Strategy

If founders cannot explain how technology supports future growth, investors may question the company's readiness for scaling.

Heavy Dependence on Individual Contributors

When critical knowledge is concentrated in a single developer, operational risk increases.

Investors generally prefer organizations that can function effectively even if key individuals leave.

Significant Technical Debt

Technical debt is normal in startups, but excessive debt can indicate deeper problems.

Warning signs include:

Frequent outages
Slow development cycles
Persistent product instability
Difficulty launching new features

These issues may raise concerns about future execution.

Lack of Engineering Processes

Investors often expect to see at least basic development standards and workflows.

Without structure, maintaining quality becomes increasingly difficult as teams grow.

How Technical Leadership Improves Fundraising Readiness

Startups with strong technical leadership often enter fundraising discussions with greater confidence.

Effective leadership can help by:

Creating a clear technology roadmap
Demonstrating scalability planning
Improving engineering processes
Reducing technical risks
Providing credible answers during due diligence

These factors can strengthen the overall investment narrative.

Investors are generally more comfortable backing companies that have a clear plan for managing future technical challenges.

Building Investor Confidence Before You Need It

One of the biggest mistakes founders make is preparing for technical due diligence only after fundraising begins.

The strongest startups treat technical readiness as an ongoing process.

This means:

Documenting important decisions
Maintaining development standards
Monitoring technical debt
Planning for future scalability
Establishing clear leadership responsibilities

By addressing these areas early, startups position themselves more effectively for future investment opportunities.

Conclusion

Investors evaluate far more than revenue numbers and market size. For technology-driven businesses, leadership, scalability, and technical execution are critical components of the funding equation.

A strong technical foundation helps reduce risk, improve credibility, and demonstrate long-term potential. As startups grow, ensuring that technology has clear ownership and strategic direction can become an important factor in both fundraising success and business growth.

Further Reference

If you need to know more about hire a cto, visit FoundersBar.

Hire a CTO or Wait? How Founders Can Make the Right Decision

Khalfan — Thu, 09 Jul 2026 10:58:28 +0000

For many startups, technology is both the product and the foundation of the business. As a company grows, the need for technical leadership becomes increasingly important. Yet many founders struggle to determine the right time to hire a CTO.

Some companies bring in executive leadership before they truly need it, creating unnecessary costs. Others postpone the decision for too long and find themselves dealing with technical debt, inefficient development processes, and scaling challenges.

The right choice depends on understanding your company's current stage and future objectives.

The Purpose of a CTO in a Startup

A Chief Technology Officer is responsible for shaping the technical direction of a company. While developers focus on building products, a CTO focuses on ensuring those products can support business growth over the long term.

Key responsibilities often include:

Defining the technology strategy
Creating scalable architecture plans
Leading engineering teams
Establishing development standards
Managing technical risks
Supporting product and business decisions

A CTO helps ensure that technology investments align with company goals rather than simply solving immediate development challenges.

Why Startups Often Delay Technical Leadership

Early-stage startups typically prioritize speed and efficiency. Resources are limited, and founders are focused on validating ideas, attracting customers, and generating revenue.

At this stage, most companies are concerned with:

Launching products quickly
Testing market demand
Collecting user feedback
Improving product-market fit

Because the business is still evolving, many startups do not yet require a full-time executive focused solely on technology strategy.

In fact, bringing in senior leadership before clear responsibilities exist can create unnecessary overhead.

How Growth Changes Technical Requirements

As startups gain traction, the complexity of managing technology increases significantly.

What once involved a few developers working on a single product can evolve into multiple teams, larger infrastructure requirements, and more demanding customer expectations.

Growth often introduces new responsibilities such as:

Infrastructure planning
Security management
Engineering recruitment
Process standardization
Performance optimization

These responsibilities require strategic oversight that extends beyond day-to-day development work.

Signs Your Startup May Need Dedicated Technical Leadership

Rather than focusing on revenue numbers or employee counts, founders should pay attention to operational signals.

Development Teams Are Expanding

As engineering teams grow, coordination becomes increasingly important.

A lack of leadership can result in:

Inconsistent coding standards
Misaligned priorities
Communication breakdowns
Slower development cycles

Technical leadership helps establish clear processes and accountability.

Product Complexity Is Increasing

Modern software products often require integrations, cloud infrastructure, security controls, and performance monitoring.

The more complex a product becomes, the greater the need for strategic technical decision-making.

Scaling Is Becoming a Priority

If customer growth is accelerating, technical systems must keep pace.

Leadership becomes valuable when companies need to:

Improve reliability
Prepare for higher traffic volumes
Support larger user bases
Build scalable development practices

Without proper planning, rapid growth can expose weaknesses in product architecture.

Technical Hiring Is a Major Focus

Recruiting engineers is not simply about filling positions. Companies need someone capable of evaluating talent, mentoring teams, and creating an environment where developers can succeed.

Technical leadership often plays a central role in building high-performing engineering organizations.

Common Mistakes Founders Should Avoid

One of the most common mistakes is assuming that hiring a CTO is a milestone every startup must reach by a certain date.

Business needs vary significantly from one company to another.

Another mistake is waiting until serious problems emerge before introducing leadership. By that point, issues such as technical debt, inefficient workflows, and team misalignment may already be slowing growth.

The most effective approach is proactive planning rather than reactive hiring.

Evaluating Your Readiness

Founders can assess their readiness by considering several questions:

Are technical decisions becoming increasingly strategic?
Is our engineering team growing?
Are scalability concerns emerging?
Do we need stronger technical processes?
Is technology central to our long-term competitive advantage?

If the answer to several of these questions is yes, it may be time to strengthen technical leadership within the organization.

The goal is not simply to fill an executive position but to ensure the business has the expertise required for its next phase of growth.

Conclusion

Every startup eventually reaches a point where technology leadership becomes essential. The challenge is identifying that moment before growth begins to outpace technical capabilities.

Rather than making decisions based on industry expectations, founders should evaluate their team's needs, product complexity, and future plans. By aligning leadership decisions with business requirements, startups can build stronger technical foundations and create a more sustainable path toward growth.

Further Reference

If you need to know more about hire a cto, visit FoundersBar.

Freelancers Without Oversight vs. Fractional CTO + Small Team: The Real Comparison

Khalfan — Wed, 08 Jul 2026 05:44:43 +0000

For early-stage startups deciding how to staff their first technical work, the practical comparison isn't usually "fractional CTO vs. full-time CTO." It's "fractional CTO with a small team vs. freelancers with no senior oversight."

Here's what each actually looks like in practice:

Freelancers, no senior oversight:

Founder defines requirements (often vague)
↓
Freelancer interprets requirements (often differently than intended)
↓
Development proceeds with no senior review
↓
Expensive architectural decisions get made without experienced judgment
↓
Founder discovers problems at demo/launch, not during development
↓
Recovery costs 4–12 weeks and significant rework budget

Fractional CTO + small team:

Fractional CTO defines architecture and requirements with founder
↓
Developers work within a clear technical direction
↓
Regular review catches drift early (cheap to fix)
↓
Progress toward a specific, defined outcome: usable MVP + traction
↓
Founder can show a working product and articulate the technical decisions

The cost difference is real. So is the output difference. The question is whether the cost of no senior oversight in rework, in delayed launches, in products that don't quite work is actually lower than the cost of bringing in someone experienced.

For most early-stage founders building their first product: it usually isn't.

Full breakdown with the comparison framework: → https://foundersbar.com/articles-and-research/when-to-hire-a-fractional-cto-vs-full-time-cto (foundersbar.com)

What a fractional CTO actually does day-to-day (it's not what most people assume)

Khalfan — Mon, 06 Jul 2026 11:33:53 +0000

One of the clearest value cases for fractional CTO support is the set of early architectural decisions that are hard to reverse and have outsized downstream impact.

Non-technical founders building their first product face a specific challenge: the decisions that matter most technically are often invisible until they've already caused expensive problems. A few examples of what this looks like in practice:

Tech stack selection for the wrong reasons choosing based on what the available freelancer knows rather than what fits the product requirements, scale expectations, and long-term hiring needs. Not always wrong, but rarely optimal.

Scalability assumptions baked in too early or too late over-engineering for scale you won't see for years, or under-engineering to the point where getting to 1,000 users requires an expensive rebuild. Both are common; neither is obvious to someone without experience.

Data model decisions that calcify the database schema you start with often follows you for longer than expected. Early decisions about how data is structured, related, and queried have compounding effects on every feature built afterward.

Third-party integration choices which external services to use, at what point in the stack to integrate them, and what happens when you need to replace one. Early lock-in to the wrong service can be expensive to unwind.

Deployment and infrastructure choices over-provisioned for an MVP, under-provisioned for demo day, or architected in a way that only one person can deploy safely.

A fractional CTO makes these calls based on experience with dozens of similar projects, not on first principles from a position of limited context. That's the actual leverage.

Full breakdown: → https://foundersbar.com/articles-and-research/when-to-hire-a-fractional-cto-vs-full-time-cto (foundersbar.com)

What's the most consequential early architectural decision you've seen go wrong at a startup?

What "Fractional CTO" Actually Means in Practice (Not the Marketing Version)

Khalfan — Fri, 03 Jul 2026 07:00:16 +0000

"Fractional CTO" has become a reasonably common term in startup circles, and like most startup terms it's accumulated a fair amount of vague or inflated meaning. Worth defining clearly from a practical standpoint.

What a fractional CTO is not, in most legitimate engagements:

A strategy consultant who produces a slide deck and leaves

Someone who only attends weekly update calls and asks questions

A "technical advisor" in name only

What a fractional CTO actually does in an early-stage context:

Defines the technical architecture for the MVP before development starts

Provides hands-on guidance during development, especially valuable when the team is freelancers or a small agency without senior oversight

Reviews code and progress with experienced eyes, catching expensive decisions early

Mentors early developers and establishes lightweight processes that scale better than no process

Course-corrects direction when development has drifted

Works toward a specific outcome: a usable, reasonably scalable MVP that can demonstrate traction and support a fundraising conversation

The "fractional" part means part-time engagement, typically 10–20 hours per month, not a reduced version of the role. The work is senior-level. The time commitment is adjusted for the stage.

For developers working at early-stage startups: you may encounter a fractional CTO as a reviewer or advisor on your work. The good ones provide meaningful technical oversight, not just sign-offs.

Full breakdown of what the role looks like in practice vs. full-time:

→ https://foundersbar.com/articles-and-research/when-to-hire-a-fractional-cto-vs-full-time-cto (foundersbar.com)

Stop Vetting Harder. Start Structuring Better.

Khalfan — Thu, 02 Jul 2026 07:47:45 +0000

The standard advice for avoiding freelancer ghosting is almost always some version of "vet more carefully." Check references. Look for a strong portfolio. Trust your gut about responsiveness in the first few conversations.

This advice isn't wrong, exactly. It's incomplete in a way that leaves founders exposed regardless of how well they vet.

Most ghosting isn't predictable from vetting because it's not primarily about the person's reliability as a trait. It's about what happens when a perfectly competent, well-intentioned freelancer hits scope creep that was never bounded, overcommitment from juggling too many clients, or a project with no clear milestones forcing accountability. These are structural conditions, not character flaws, and they can happen to a freelancer who interviewed beautifully and delivered great early work.

The fix that actually reduces risk isn't a better screening process. It's structure built into the engagement itself, regardless of who's doing the work:

A technical blueprint before development starts, removing the ambiguity that fuels scope creep. Milestone-based phases with explicit deliverables, creating natural checkpoints that surface problems early instead of letting them silently accumulate. Mandatory documentation as part of every completed phase, so knowledge doesn't live exclusively in one person's head. Some layer of continuity, a second technical reviewer, even periodically, so the founder isn't solely dependent on one person's self-reporting of progress.

None of this requires distrust of freelancers as a category. It requires acknowledging that even trustworthy people operate within systems, and a system with no structural protections is fragile regardless of who's in it.

Full framework for building structural resilience into freelance engagements on Foundersbar.

→ https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp

A Practical Framework for Building an MVP Without a Single Point of Failure

Khalfan — Wed, 01 Jul 2026 13:20:39 +0000

The Mindset Shift

The goal isn't avoiding freelancers. Many excellent MVPs have been built with freelance talent. The real shift is from "hire someone to build it" to "build with resilience and knowledge continuity designed in from the start" treating early development as risk management, not just a building exercise.

The Five-Part Framework

Start with a proper technical or product blueprint

Before writing significant code, invest in clarifying requirements, user flows, technical decisions, and success criteria. This reduces scope creep, one of the most common root causes of ghosting, and creates a shared reference document that makes onboarding a replacement dramatically easier if needed.

Use clear, milestone-based phases

Element

Purpose

Specific deliverables per phase

Creates checkpoints for evaluating progress objectively

Clear acceptance criteria

Removes ambiguity about what "done" means

Knowledge transfer at each phase completion

Ensures understanding isn't concentrated in one person's head

Make documentation and handover non-negotiable

Reasonable code comments, architecture notes, and documentation should be deliverables, not optional extras. This is what protects a founder if a provider switch becomes necessary.

Add continuity and oversight

A small team instead of a solo freelancer, or periodic technical review from a second person. Even light project management and progress tracking dramatically reduces single-person risk.

Design for optionality

Structure agreements and work so the founder can pause, adjust scope, or bring in additional help without starting from scratch. Fixed-scope phases with clear ownership make this possible.

The Net Effect

None of these five changes require a significantly larger budget. They require treating structure as part of the build, not overhead on top of it.

Full framework, including what to do if you're currently dealing with a stalled project, on FoundersBar.

→ Read the full article: https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp

foundersbar.com

Your MVP Developer Disappeared. Here's What To Do Next.

Khalfan — Tue, 30 Jun 2026 12:02:43 +0000

Few situations create more panic for a founder than realizing the person building the product has stopped responding.

The project stalls. Progress becomes unclear. And the immediate question becomes:

"Do we have to start over?"

In most cases, the answer is no.

Recovery is usually possible, but the first few decisions matter.

Step 1: Secure everything you already have

Gather all available assets:

• Source code repositories
• Messages and emails
• Design files
• Login credentials
• Hosting and deployment access
• Project notes and documentation

Even incomplete information is valuable. The goal is preserving context before anything else gets lost.

Step 2: Determine what's actually usable

Many founders assume a stalled project automatically means a rewrite.

That's often not true.

Some parts of the system may be perfectly usable, while others need improvement or replacement. An independent technical review can help separate valuable work from technical debt.

Without this assessment, founders often make one of two expensive mistakes:

Discarding good work or keeping bad work.

Step 3: Define the remaining scope clearly

A stalled project is an opportunity to introduce structure.

Document:

• What has been completed
• What remains unfinished
• What success looks like
• What documentation is required moving forward

This creates clarity for everyone involved in the recovery process.

Step 4: Bring in experienced guidance

Recovery projects are different from greenfield projects.

The challenge isn't just building new features. It's understanding existing decisions, evaluating quality, and restoring momentum without introducing new risks.

This is often where technical advisors, structured development partners, or experienced product teams provide the most value.

Step 5: Build the second version with resilience

The best recoveries don't simply restart development.

They fix the conditions that made the project vulnerable in the first place.

Better documentation.

Clear milestones.

Knowledge transfer.

Shared visibility.

Continuity beyond one person.

The goal isn't just finishing the MVP.

It's making sure the next unexpected disruption doesn't stop the company again.

Full recovery framework and resilient MVP development guide:

→ https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp (foundersbar.com)

Solo Freelancer vs Small Team for Your MVP: The Real Tradeoffs

Khalfan — Mon, 29 Jun 2026 12:18:57 +0000

Most MVP hiring decisions get framed around one question:

"What's cheaper?"

The more useful question is:

"What happens if something goes wrong?"

A solo freelancer has obvious advantages. Lower cost. Faster communication. Less coordination overhead. One person making decisions and writing code can move surprisingly fast, especially on a focused MVP.

But the tradeoff is equally obvious.

A solo freelancer creates a bus factor of 1 by default.

If they become unavailable, whether through overcommitment, burnout, illness, or simply moving on, your entire product can stall overnight. There's often no second person who understands the architecture, deployment process, or technical decisions behind the code.

A small team or structured development partner changes that equation.

Progress may be slightly slower at the beginning because coordination exists. Costs are usually higher. But redundancy is built into the process. Documentation tends to happen naturally. Knowledge is shared across multiple people. If one person leaves, the project doesn't immediately freeze.

The mistake many founders make is treating this as an either-or decision.

The practical middle ground is often a solo developer with structure:

• Milestone-based delivery instead of open-ended work
• Documentation requirements built into every phase
• Regular code reviews or oversight from a second technical person
• Clear ownership of infrastructure and access credentials
• Knowledge transfer throughout the project, not just at the end

This preserves much of the speed and cost advantage of a solo freelancer while reducing the risk that your entire MVP depends on one person's availability.

The goal isn't to eliminate risk.

It's to avoid discovering that your entire company was sitting on a single point of failure.

Full framework comparing solo freelancers, small teams, and hybrid approaches: → https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp (foundersbar.com)

What's worked best for you: solo freelancer, small team, or something in between?

The 4-to-12-Week Tax: What Getting Ghosted on Your MVP Actually Costs

Khalfan — Fri, 26 Jun 2026 12:35:28 +0000

Most founders calculate the cost of a ghosted developer by looking at the money they've already paid.

That's usually the smallest number in the equation.

The real cost starts after the freelancer disappears.

Getting a replacement developer up to speed typically takes 4 to 12 weeks, sometimes longer. Not 4 to 12 weeks of building new features. 4 to 12 weeks of understanding what already exists, identifying what's usable, and reconstructing decisions that were never documented.

At a conservative development cost of $8,000 to $10,000 per month, that's potentially $8,000 to $30,000 in recovery costs alone. And that's before accounting for what was already spent on the original project.

The hidden costs are often worse:

Momentum
Every week spent recovering is a week competitors spend shipping, learning from users, and improving their product.

Context
Code can be inherited. Decision-making cannot. When documentation is missing, the reasoning behind technical choices disappears with the person who made them.

Runway
For bootstrapped and pre-seed founders, unexpected delays don't just impact timelines. They shorten the runway available to reach the next milestone.

Morale
Few things drain founder confidence faster than discovering that months of work are effectively locked behind someone who is no longer available.

The uncomfortable reality is that most of these costs are preventable.

Milestone-based delivery. Documentation requirements. Knowledge transfer. Basic continuity planning.

All cost a fraction of what recovery costs after something goes wrong.

The math isn't complicated. The surprising part is how few founders calculate it before they experience it firsthand.

Full cost breakdown and the prevention framework on FoundersBar.

→ https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp

foundersbar.com | Practical resources for founders building resilient products.

The Documentation Habits That Protect Your MVP From a Single Developer's Departure

Khalfan — Fri, 26 Jun 2026 12:14:17 +0000

If your MVP depends entirely on one developer's knowledge, you have a bus factor of 1, and you're one unavailable person away from a project stall, regardless of whether that unavailability is ghosting, illness, or just a sudden new opportunity.

Here's what minimum-viable documentation looks like for an early-stage MVP, achievable without slowing down development meaningfully.

Architecture overview (1 page): What the major components are and how they connect. Doesn't need to be exhaustive. It needs to be enough that someone else could orient themselves without weeks of code archaeology.

Decision log:

Why did we choose X over Y?
What were we optimizing for?
What would make us reconsider this choice?

Five minutes per significant decision. Saves weeks for whoever inherits the project.

Setup and deployment notes: The undocumented stuff that lives only in one person's head, environment variables, deployment quirks, third-party service configurations. This is consistently the hardest thing to reconstruct after a developer disappears.

Milestone-based deliverables with explicit "what's done" criteria: Not just code shipped. A brief explanation of what was built and why, attached to each completed phase.

Code comments at decision points: Not comments explaining what the code does. The code should do that. Comments explaining why a non-obvious approach was chosen.

None of this requires a large time investment relative to the cost of reconstructing it after a developer becomes unavailable, which research suggests can take 4 to 12+ weeks of recovery time.

Full breakdown on the resilient MVP framework: → https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp (foundersbar.com)

Why Freelance Developers Ghost Clients (A Look From Both Sides)

Khalfan — Fri, 26 Jun 2026 11:59:28 +0000

Freelancer ghosting gets discussed almost exclusively from the founder's perspective: developer disappears, project stalls, founder is left holding incomplete code. It's worth examining the other side too, because understanding why it happens is the key to preventing it.

Ghosting is rarely random or malicious. The common patterns:

Scope creep without boundaries. The project that started clear keeps expanding. New features get added, priorities shift, and the original agreement becomes blurry. At some point, continuing to absorb unplanned work without adjusted compensation or timeline becomes unsustainable, and disengagement follows.

Overcommitment. Freelancers juggling multiple clients sometimes take on more than they can sustain. When a higher-paying or less stressful opportunity appears, smaller or less structured projects get deprioritized first, not out of malice, but out of triage.

Lack of project structure. Vague requirements and missing milestones make it easy for things to drift on both sides. Without clear checkpoints, there's no forcing function for an honest conversation about scope or timeline.

Communication breakdown. Delayed founder feedback, slow decision-making, or difficult dynamics can push a freelancer toward quietly exiting rather than confronting friction directly.

Personal factors. Health issues, family emergencies, sudden full-time offers. Even reliable people sometimes can't manage a proper handover.

For developers: clear milestone structure and documentation requirements protect you too. They create a paper trail of completed work and reduce the ambiguity that turns a manageable project into an overwhelming one.

For founders: the structural fix isn't "vet harder," it's building process into the engagement from day one.

Full breakdown: → https://foundersbar.com/articles-and-research/how-to-avoid-freelancer-ghosting-when-building-an-mvp (foundersbar.com)

If you've freelanced, what made a project sustainable vs. one that pushed you toward disengaging?