The Reality of IR35 in the UK Software Industry
The conversation around ir35 software contractors is no longer theoretical. For UK startups, it has become a structural constraint that directly shapes hiring, delivery speed, and even product timelines.
IR35, or off-payroll working legislation, was designed to tackle “disguised employment.” In practice, it has fundamentally altered how software engineers, testers, and technical specialists engage with companies. The shift is especially visible in the startup ecosystem, where flexibility has historically been a competitive advantage.
For early-stage companies, contractors were never just a cost decision. They were a strategic lever. Need a senior backend engineer for three months? Bring in a contractor. Scaling a DevOps pipeline quickly? Hire a specialist. This fluid model allowed startups to move faster than larger organisations.
IR35 disrupts that model.
Since the private sector reforms in 2021, responsibility for determining employment status has shifted to the hiring organisation. That means startups, not contractors, now carry the compliance burden. Misclassification can lead to significant tax liabilities, penalties, and reputational risk.
This is where things get complicated.
Software roles rarely fit into clean categories. A contractor might work autonomously, deliver outcomes, and operate like a business entity. But if they are embedded deeply into a team, attend daily stand-ups, or follow internal processes too closely, they may be deemed “inside IR35.”
The nuance is critical.
In the UK software industry, roles such as backend developers, cloud engineers, and platform specialists often sit in a grey area. They are highly skilled, outcome-driven, and independent in theory. Yet modern engineering practices such as Agile, Scrum, and DevOps create environments that resemble employment structures.
This creates tension between how work is delivered and how it is legally classified.
From a market perspective, the impact is already visible. Many contractors now actively seek “outside IR35” roles to preserve their tax efficiency. At the same time, companies are becoming more cautious, sometimes defaulting to “inside IR35” determinations to reduce risk.
The result is a fragmented hiring landscape.
Startups now face a difficult balancing act. On one hand, they need access to top-tier engineering talent. On the other, they must navigate compliance frameworks that were not designed with modern software delivery models in mind.
This is particularly challenging for companies without in-house legal or tax expertise.
In many cases, founders underestimate how early IR35 considerations should enter their planning. It is not just a finance or HR issue. It intersects with technical decision-making, team structure, and even architecture choices.
For example, a company investing in scalable systems and modular design may rely more heavily on short-term specialist contractors. But without a clear understanding of IR35 implications, that strategy can introduce hidden risk.
This is why aligning technical and operational strategy matters. Resources like technical due diligence for startups can help identify structural risks early, while frameworks such as the build vs buy decision model can influence how much reliance is placed on external contractors versus internal teams.
Another layer of complexity comes from the growing ecosystem of compliance tools. The rise of ir35 compliance software uk, ir35 assessment software, and ir35 status determination software reflects how widespread the challenge has become. Yet tools alone cannot solve a fundamentally strategic problem.
At its core, IR35 is forcing startups to rethink how they define “work relationships” in a software context.
The traditional contractor model assumed clear separation between client and supplier. Modern engineering practices blur that line. Continuous integration, collaborative tooling, and shared ownership of codebases create environments where independence is harder to demonstrate.
For startups operating at speed, this creates friction.
They must now design not only scalable systems but also compliant working structures. And unlike larger enterprises, they do not have the luxury of absorbing mistakes.
Understanding the reality of IR35 in the software industry is the first step. It is not just a tax rule. It is a constraint that influences how startups hire, build, and scale in the UK market.
Why IR35 Creates Strategic Risk for Tech Startups
For startups, ir35 software contractors are not just a hiring option. They are often the backbone of early execution. When IR35 enters the picture, it introduces risk at a level that many founders don’t initially anticipate.
This risk is not isolated to compliance. It spreads across finance, hiring, delivery timelines, and even investor confidence.
At a financial level, the impact is immediate. If a contractor is deemed “inside IR35,” the company becomes responsible for employer National Insurance contributions and PAYE tax deductions. This can increase the effective cost of a contractor by 20–30 percent.
For a startup managing tight runway, that shift is significant.
What makes it more complex is the unpredictability. A role that appears outside IR35 today may be reassessed later. If HMRC challenges the determination, liability can be applied retrospectively. That means unexpected tax bills, penalties, and administrative overhead at the worst possible time.
But the financial layer is only one part of the story.
Operationally, IR35 changes how startups approach hiring. The traditional model of quickly onboarding a specialist contractor becomes slower and more cautious. Status determinations, contract structuring, and documentation add friction to what used to be a fast decision.
This directly affects delivery speed.
For example, a startup building an MVP may rely on external engineers to accelerate development. If those roles are classified inside IR35, the cost increase may force trade-offs such as reducing scope, extending timelines, or shifting to less experienced talent.
This is where IR35 becomes a strategic constraint rather than a legal one.
There is also a talent market dimension. Highly skilled contractors, especially those operating as outside ir35 software engineer profiles, are increasingly selective. Many avoid roles that fall inside IR35 because of reduced take-home pay and loss of flexibility.
As a result, startups competing for top-tier talent are at a disadvantage if they cannot confidently offer outside IR35 engagements.
This creates a talent bottleneck.
At the same time, internal teams feel the impact. Engineering leaders must now think about how work is structured. If contractors are embedded too deeply into sprint cycles or managed like employees, the risk of inside IR35 classification increases.
That means delivery processes themselves can become a liability.
In parallel, there is a growing reliance on tools such as ir35 compliance software, ir35 and payroll software, and broader hr software for ir35 compliance. These systems aim to standardise assessments and reduce human error. However, they often operate on predefined criteria that may not fully capture the nuances of software delivery environments.
In other words, tools can support decisions but cannot replace judgement.
Another overlooked risk is reputational. Investors and stakeholders expect startups to demonstrate operational maturity. Mismanaging contractor relationships or facing compliance issues can signal weak governance.
For companies preparing for funding rounds or due diligence, this becomes a serious concern.
This is why financial planning and infrastructure decisions need to align with compliance realities. For instance, optimising burn rate through strategies outlined in cloud cost optimization for startups can help offset increased contractor costs. Similarly, adopting structured engineering practices through DevOps for startups can create clearer boundaries between internal teams and external contributors.
The key point is this.
IR35 forces startups to think more deliberately about how they scale. It challenges the assumption that flexibility is always low-risk. Instead, it introduces a trade-off between speed and compliance.
For founders and CTOs, the question is no longer “Should we use contractors?” It becomes “How do we use them without exposing the business to hidden risk?”
That shift in thinking is what separates reactive companies from those that build resilient, scalable systems from the start.
Inside vs Outside IR35: What It Actually Means for Software Teams
For many founders and engineering leaders, the distinction between “inside” and “outside” IR35 feels abstract. In reality, it directly shapes how ir35 software contractors are hired, managed, and integrated into delivery teams.
At a high level, the classification determines whether a contractor is treated as an independent business or as a deemed employee for tax purposes. But in software environments, the difference is rarely obvious.
An outside IR35 software engineer typically operates as a genuine supplier. They deliver defined outcomes, retain control over how work is completed, and maintain a clear separation from internal team structures. Their engagement is project-based rather than role-based.
On the other hand, an inside IR35 software developer is effectively treated like an employee from a tax perspective. They may still be labelled a contractor, but their working relationship mirrors that of a permanent team member.
The challenge lies in how modern engineering teams actually function.
Most startups rely on collaborative workflows. Daily stand-ups, sprint planning, shared repositories, and continuous integration pipelines are standard practice. These structures are designed to improve delivery speed and product quality.
However, they also blur the boundaries that IR35 tries to define.
For example, a software tester outside ir35 might be engaged to deliver a specific testing framework or automation suite. If they work independently, define their own approach, and deliver outcomes without direct supervision, the engagement leans towards outside IR35.
But if that same tester joins daily stand-ups, follows internal QA processes, and reports to a team lead, the relationship starts to resemble employment.
This is where risk emerges.
Control, substitution, and mutuality of obligation are the three key factors often used in IR35 assessments. In software teams, all three can become ambiguous.
Control is especially tricky. Engineering leaders naturally want consistency in how code is written, reviewed, and deployed. But enforcing too much control over how a contractor works can shift the classification towards inside IR35.
Substitution is another factor. In theory, an outside IR35 contractor should be able to provide a substitute to complete the work. In practice, startups often hire individuals for their specific expertise, making substitution unlikely or impractical.
Mutuality of obligation adds further complexity. If a company expects continuous work and the contractor expects ongoing payment beyond a defined project scope, the relationship starts to mirror employment.
These nuances are difficult to manage in fast-moving environments.
From a structural perspective, startups need to think carefully about how work is defined. Outcome-based contracts, clearly scoped deliverables, and limited integration into internal processes can help maintain an outside IR35 position.
This is easier said than done.
Engineering models such as platform-based development or modular architectures can support this approach. By breaking systems into independent components, startups can assign discrete deliverables to contractors without embedding them deeply into the core team. Concepts explored in platform engineering vs DevOps highlight how structuring teams and systems can influence ownership and boundaries.
Similarly, adopting secure and well-defined workflows through practices outlined in DevSecOps best practices can help maintain clarity around responsibilities without excessive micromanagement.
The reality is that IR35 forces a rethink of how collaboration is structured.
It is no longer enough to simply hire a contractor and plug them into a team. The way tasks are assigned, how communication happens, and how performance is measured all contribute to the classification.
For startups, this creates a tension between efficiency and compliance.
Highly integrated teams deliver faster. But the more integrated a contractor becomes, the harder it is to justify an outside IR35 status. Conversely, maintaining strict separation can reduce risk but may slow down delivery or reduce cohesion.
There is no universal solution.
Instead, startups must make deliberate choices based on their priorities. Understanding what “inside” and “outside” IR35 actually mean in a software context is essential to making those decisions with clarity and confidence.
Common Compliance Mistakes Startups Make with Contractors
When it comes to ir35 software contractors, most startups don’t intentionally take risks. The problem is rarely negligence. It’s usually a lack of structural understanding combined with the pressure to move fast.
That’s exactly where mistakes begin to compound.
One of the most common errors is treating IR35 as a one-time checkbox exercise. Founders may use ir35 assessment software or rely on a template-based determination, assume the role is “outside IR35,” and move on.
In reality, IR35 is not static.
A contractor’s status can change based on how the engagement evolves. A project that starts as outcome-based can gradually shift into an ongoing role. As responsibilities expand and integration deepens, the original determination may no longer hold.
Failing to reassess is a critical mistake.
Another frequent issue is poorly structured contracts. Many startups use generic agreements that do not clearly define deliverables, substitution rights, or independence. Without explicit language, it becomes difficult to defend an outside IR35 position.
But even well-written contracts can fall short if they don’t reflect actual working practices.
This disconnect between “contract on paper” and “reality in practice” is one of the biggest risks. A company might state that a contractor has autonomy, yet still require them to follow internal processes, attend all meetings, and report to a manager like a permanent employee.
From HMRC’s perspective, behaviour outweighs documentation.
Startups also tend to underestimate the impact of control. In engineering environments, enforcing coding standards, tooling choices, and delivery timelines is normal. But when that control extends into how a contractor performs their work, it can shift the engagement inside IR35.
This is particularly common in Agile teams.
Daily stand-ups, sprint commitments, and shared ownership models can unintentionally create employment-like conditions. While these practices are essential for delivery, they must be balanced carefully when working with contractors.
Another mistake is over-reliance on tools.
The rise of ir35 compliance software, ir35 status determination software, and broader contractor management software uk has made assessments more accessible. However, these tools often rely on predefined questionnaires and logic trees.
They can highlight risk signals, but they cannot fully interpret the nuances of a specific engineering setup.
Treating software outputs as definitive answers is risky.
There is also a tendency to apply blanket decisions. Some startups, especially those without legal guidance, default to classifying all contractors as inside IR35 to avoid complexity. While this reduces compliance risk, it creates other problems.
Top-tier contractors often avoid inside IR35 roles. This approach can limit access to high-quality talent and increase costs, as contractors may demand higher rates to compensate.
On the other end of the spectrum, some companies aggressively classify roles as outside IR35 without sufficient justification. This exposes them to potential investigations and financial penalties.
Both extremes are problematic.
A more subtle mistake is failing to align IR35 considerations with broader technical and operational strategy. For example, bringing in multiple contractors to work on tightly coupled systems increases the likelihood of deep integration.
Without careful planning, this can push engagements towards inside IR35.
This is where structured evaluation becomes important. Approaches similar to those used in technical due diligence for startups can help identify hidden risks in how teams are organised and how work is delivered. Likewise, disciplined delivery practices outlined in continuous deployment strategies can create clearer boundaries around ownership and responsibility.
Finally, many startups simply react too late.
IR35 is often considered only after contractors are already engaged. By that point, changing working practices or restructuring contracts becomes difficult without disrupting delivery.
The smarter approach is proactive.
Understanding these common mistakes is not just about avoiding penalties. It’s about building a hiring and delivery model that can scale without introducing hidden liabilities.
Building an IR35-Safe Contractor Strategy
For startups relying on ir35 software contractors, avoiding mistakes is only the first step. The real advantage comes from designing a contractor strategy that is compliant by default, not corrected after the fact.
This requires a shift in thinking.
Instead of asking whether a role is inside or outside IR35 after hiring, startups need to design roles, workflows, and engagement models that naturally align with compliance requirements from the beginning.
At the core of an IR35-safe strategy is clarity of intent.
Contractors should be engaged to deliver outcomes, not to fill roles. This may sound like a small distinction, but it has major implications. A role-based approach, such as hiring a “backend developer for six months,” often leads to deep integration into the team.
An outcome-based approach, such as delivering a specific API module or scaling a cloud architecture, creates clearer boundaries.
This is where many startups need to rethink how they structure work.
Breaking projects into modular components allows external contributors to operate independently. Instead of embedding contractors into core teams, they can be assigned ownership of defined deliverables with minimal day-to-day supervision.
This aligns more naturally with outside IR35 conditions.
Architectural decisions play a role here. Systems designed with modularity and separation of concerns make it easier to allocate work externally without creating dependency on internal processes. Concepts explored in composable architecture for startups provide a useful foundation for this approach.
Another critical element is contract design.
Contracts must clearly reflect the intended working relationship. This includes defining deliverables, outlining the contractor’s autonomy, and addressing substitution rights where appropriate. However, the contract alone is not enough.
It must be supported by actual working practices.
This means engineering leaders need to be deliberate about how contractors are managed. Limiting mandatory meetings, avoiding direct line management structures, and focusing on output rather than activity can help maintain the distinction between contractor and employee.
Of course, this introduces operational challenges.
Startups thrive on collaboration. Removing contractors from core workflows can feel counterintuitive. But the goal is not isolation. It is structured independence. Communication should still happen, but it should be centred around deliverables rather than continuous supervision.
Hiring strategy also needs to evolve.
Rather than sourcing generalists to plug gaps, startups should prioritise specialists who can deliver clearly scoped outcomes. This aligns better with ir35 recruitment software workflows and reduces ambiguity in role definition.
It also makes it easier to justify outside IR35 classifications.
From an operational perspective, tracking and governance become important. Using systems such as contractor tracking software or independent contractor management software can help maintain visibility over engagements. These tools can support documentation, track deliverables, and ensure consistency across contractor relationships.
However, like compliance tools, they should support strategy, not define it.
Financial planning is another key consideration. Startups need to account for the possibility that some roles will fall inside IR35. Building this into cost models avoids last-minute surprises and allows for more informed decision-making.
Frameworks such as the build vs buy decision model can help determine when it makes sense to rely on contractors versus investing in permanent hires. Similarly, aligning hiring decisions with long-term goals outlined in a product market fit roadmap ensures that contractor usage supports, rather than disrupts, growth.
Ultimately, an IR35-safe strategy is about alignment.
It aligns legal compliance with technical architecture, hiring practices, and delivery models. Startups that treat these elements in isolation often struggle. Those that integrate them early create a more resilient foundation.
IR35 does not eliminate the value of contractors. It simply requires startups to use them more deliberately.
The Role of IR35 Software and Contractor Management Tools
As IR35 complexity has increased, so has the ecosystem of tools designed to manage it. For startups working with ir35 software contractors, these platforms promise clarity, automation, and reduced compliance risk.
But the reality is more nuanced.
At a surface level, tools such as ir35 payroll software, ir35 compliance software, and ir35 assessment software aim to standardise decision-making. They typically guide users through structured questionnaires based on HMRC criteria, generating a status determination at the end.
This creates a sense of certainty.
However, software environments are rarely standardised. Engineering teams operate in dynamic, evolving contexts where roles shift, responsibilities expand, and collaboration models change over time.
This makes static assessments inherently limited.
IR35 tools are useful for documentation and consistency. They ensure that decisions are recorded, processes are followed, and evidence is available if needed. In that sense, they act as a compliance layer.
But they should not be treated as decision-makers.
For example, a tool might classify a role as outside IR35 based on initial inputs. Yet if the contractor becomes embedded in daily stand-ups, follows internal workflows, and operates under direct supervision, the real-world engagement may contradict the assessment.
This gap between system output and operational reality is where risk emerges.
Beyond assessment tools, there is a broader category of contractor-focused platforms. These include contractor accounting software, payroll software for contractors, and contractor invoice software. While not specific to IR35, they play a role in how contractor relationships are structured and managed.
They influence visibility, financial tracking, and administrative control.
For startups, the challenge is integration.
Using multiple disconnected tools can create fragmented workflows. One system handles compliance, another manages payments, and a third tracks contractor activity. Without alignment, this increases operational overhead and introduces inconsistencies.
A more effective approach is to think in terms of systems, not tools.
How does IR35 compliance fit into your broader engineering and operational stack? How do contractor workflows integrate with delivery pipelines, financial systems, and reporting structures?
These are architectural questions, not just administrative ones.
In some cases, building tailored internal systems may offer better alignment than relying entirely on off-the-shelf solutions. This is particularly relevant for startups with unique delivery models or complex contractor ecosystems. Exploring options through custom software development in the UK can provide flexibility where generic tools fall short.
At the same time, cost efficiency remains important. Subscription-based tools can quickly add up, especially when combined with payroll and accounting platforms. Applying principles from cloud cost optimization for startups can help evaluate whether the value delivered by these tools justifies their cost.
Another important consideration is data ownership.
Contractor management tools often store sensitive information related to contracts, payments, and compliance decisions. Startups need to ensure that data governance is aligned with their broader security and operational standards.
This is particularly critical as teams scale.
Ultimately, IR35 tools should be viewed as enablers, not solutions.
They can streamline processes, reduce manual effort, and provide a level of structure. But they cannot replace strategic thinking about how contractors are engaged and how work is delivered.
Startups that rely solely on software risk creating a false sense of compliance.
The more effective approach is layered. Use tools to support assessments, manage documentation, and handle financial processes. At the same time, ensure that underlying workflows, contracts, and team structures are aligned with IR35 principles.
In other words, technology should reinforce strategy, not compensate for its absence.
Operationalising IR35: Processes, Contracts, and Engineering Workflows
Understanding IR35 is one thing. Making it work in a live environment is something else entirely. For startups dealing with ir35 software contractors, the real challenge lies in translating theory into day-to-day operations without slowing down delivery.
This is where most friction appears.
Operationalising IR35 means embedding compliance into how work is structured, how teams collaborate, and how contracts are executed. It is not a separate layer. It must exist inside the delivery engine itself.
The first layer is process design.
Startups need clearly defined onboarding and offboarding workflows for contractors. This includes structured IR35 assessments, documented status determinations, and consistent contract templates. But beyond paperwork, processes must define how contractors interact with the team.
For example, instead of defaulting to full integration, contractors can be engaged through defined interfaces. They receive scoped deliverables, agreed timelines, and limited dependencies on internal team members.
This reduces ambiguity.
The second layer is contract alignment.
Contracts must reflect operational reality. If a contractor is expected to deliver a specific module or system component, that should be explicitly defined. Clauses around autonomy, substitution, and deliverables must match how work is actually performed.
Misalignment between contract and practice is one of the most common failure points.
This is where many startups struggle. Engineering teams often prioritise speed and collaboration, while legal frameworks require separation and clarity. Bridging this gap requires coordination between technical and operational leadership.
Engineering workflows play a critical role here.
Modern development practices such as CI/CD, shared repositories, and collaborative sprint cycles can unintentionally increase IR35 risk. If contractors are treated as core team members, with continuous oversight and integration, the engagement may lean towards inside IR35.
That does not mean these practices need to be abandoned.
Instead, they need to be structured differently.
For instance, contractors can work on isolated branches, deliver through defined handoff points, and avoid full participation in internal ceremonies. Communication can remain active, but focused on outcomes rather than continuous supervision.
Adopting structured delivery models from DevOps for startups can help maintain efficiency while preserving clearer boundaries. Similarly, implementing disciplined release workflows through continuous deployment strategies ensures that contractor contributions are integrated without requiring deep operational control.
Infrastructure design also matters.
Platforms built on scalable systems, such as those outlined in Kubernetes for startups, allow for better isolation of services and components. This makes it easier to assign independent workstreams to contractors without embedding them into the core system.
The third layer is governance and tracking.
Using systems such as contractor job management software, contractor scheduling software, and contractor compliance software can provide visibility into how engagements are structured and executed. These tools help track deliverables, timelines, and contractual obligations.
But again, they must reflect reality.
Tracking systems that show independent deliverables while actual work is tightly controlled internally will not hold up under scrutiny. Consistency between systems, contracts, and behaviour is essential.
Finally, there is the human factor.
Engineering leaders and project managers need to understand IR35 implications. Without awareness, even well-designed processes can break down in practice. Simple decisions, such as assigning tasks or scheduling meetings, can shift the nature of an engagement.
Training and alignment across teams are critical.
Operationalising IR35 is not about restricting how teams work. It is about designing workflows that balance collaboration with independence. Startups that achieve this balance can continue to move fast while maintaining compliance.
Those that do not often find themselves caught between efficiency and risk, forced to make reactive adjustments under pressure.
Future-Proofing Your Startup Against IR35 and Workforce Shifts
IR35 is not a temporary disruption. It is part of a broader shift in how work, taxation, and employment are structured in the UK. For startups relying on ir35 software contractors, the real question is not just compliance today, but resilience over the next few years.
Workforce models are evolving.
The traditional mix of permanent employees and flexible contractors is becoming more complex. Companies are now balancing full-time hires, inside IR35 contractors, outside IR35 specialists, and even global remote talent. Each comes with different cost structures, legal implications, and operational constraints.
This creates both risk and opportunity.
Startups that treat IR35 as a narrow compliance issue will continue to react to changes. Those that take a broader view can use it as a forcing function to build stronger, more scalable systems.
The first step in future-proofing is strategic clarity.
Founders and CTOs need to define what role contractors play in their long-term model. Are they a core part of delivery, or a temporary acceleration mechanism? Are they used for niche expertise, or as an extension of the engineering team?
Clear answers shape everything that follows.
If contractors remain a key part of the strategy, then investing in structured engagement models becomes essential. This includes consistent use of contractor management software, well-defined onboarding processes, and alignment between legal, financial, and technical teams.
It also means accepting that not every role can or should be outside IR35.
Some positions, particularly those deeply integrated into product development, may naturally fall inside IR35. Planning for this, rather than resisting it, allows startups to build realistic cost models and avoid last-minute disruptions.
The second step is architectural thinking.
How systems are designed directly influences how teams operate. Modular, decoupled architectures make it easier to assign independent workstreams to contractors. This reduces the need for deep integration and supports more flexible engagement models.
In contrast, tightly coupled systems increase dependency and blur boundaries, making compliance harder to maintain.
This is why aligning technical strategy with workforce planning is critical. Insights from technical due diligence for startups can help identify structural risks early, while broader service frameworks available through TheCodeV services can support long-term system design and execution.
The third step is building internal capability.
Relying entirely on external contractors for critical systems creates vulnerability. Over time, startups should aim to balance external expertise with strong internal teams. This reduces dependency and provides greater control over delivery.
At the same time, maintaining access to specialist contractors remains valuable. The goal is balance, not replacement.
Technology will also continue to evolve.
The growing adoption of ir35 compliance software uk, independent contractor management software, and integrated payroll systems reflects a move towards more automated governance. These tools will become more sophisticated, but they will not eliminate the need for strategic decision-making.
Startups that understand this will use technology to enhance their processes, not define them.
Finally, there is the external environment.
Regulation is unlikely to remain static. Changes to tax policy, employment law, or enforcement practices could further reshape how contractors are used. Startups need to stay informed and adaptable.
This is particularly important for companies operating in high-growth or regulated sectors.
Future-proofing is not about predicting every change. It is about building systems that can adapt without breaking. That includes flexible hiring models, scalable architectures, and clear governance structures.
For founders and engineering leaders, IR35 is ultimately a design constraint.
Handled poorly, it slows growth and limits access to talent. Handled well, it encourages better structure, clearer thinking, and more resilient systems.
If your startup is navigating these challenges and needs a structured approach to aligning engineering, hiring, and compliance, you can explore a tailored discussion through a consultation with TheCodeV.
