A custom software project involves much more than technical expertise: it fundamentally shapes an organization’s structure, teams and trajectory. Adopting a clear stance on what we refuse to do is part of our professional responsibility.
By refusing certain practices—deliveries without proper scoping, vendor lock-in, low-cost offers, rushed projects or unrealistic promises—we lay the groundwork for healthy collaboration. This approach ensures relevant, sustainable solutions aligned with the business objectives of Swiss stakeholders, whether they are IT Directors, CIOs/CTOs, COOs or executive management.
In-Depth Understanding of Business Needs
We refuse to deliver software without a thorough understanding of business challenges. We believe every project demands a robust scoping phase and a critical review of requirements.
Scoping and Functional Alignment
A project built without a detailed scoping phase often relies on incomplete or outdated assumptions. This lack of overall vision prevents anticipating friction points between existing processes and the future software solution. It also denies decision-makers a clear map of priorities, risks and critical milestones.
Scoping is not just a documentation exercise: it is a collaborative session among business experts, IT leaders and stakeholders aimed at identifying operational constraints and formalizing strategic objectives. This phase must rely on analyses of real use cases, workshops and sometimes validation prototypes.
By integrating regular feedback from end users from the very beginning, we avoid major discrepancies between the delivered product and actual needs. The investment made during scoping then results in smoother development cycles, increased adoption and a significant reduction in post-deployment adjustments.
Consequences of Insufficient Understanding
When business objectives are not clarified, software may appear technically compliant yet remain unsuitable for daily use. Teams may bypass the tool, maintain parallel manual processes or apply local workarounds to compensate for perceived shortcomings.
This situation creates functional technical debt: every quick customization becomes a breaking point during future upgrades, inflating maintenance costs and complicating updates. In the long run, the tool survives more by inertia than by delivering real added value.
Lack of user buy-in can also boomerang on project sponsorship, undermining trust among IT Directors, management and the service provider. Once this trust is eroded, it becomes very difficult to restore without starting new audit and redesign phases.
Concrete Example of Inadequate Scoping
A Swiss SME in the logistics sector launched an internal portal without a thorough scoping workshop. Business teams discovered too late that certain storage rules and delivery-deadline constraints were not taken into account. Each omission led to several additional hours of manual work per week.
In the end, although the software was technically complete, it was set aside pending a full redesign of business rules. This example demonstrates that not allocating time to formalize requirements can result in double investment: the initial development and a full project restart a few months later.
It also highlights the importance of valuing the scoping phase upfront, recognizing it in the commercial proposal as a standalone stage essential for project success and team adoption.
Opposition to Vendor Lock-In
We refuse all forms of vendor lock-in, whether technological, contractual or operational. We favor open, well-documented and reversible architectures that ensure independence and longevity.
Dangers of Vendor Lock-In
Choosing a proprietary solution without an exit plan exposes the company to heavy reliance on a vendor or service provider. Every update or modification becomes a tacit renegotiation of rates and terms. This leads to vendor lock-in, longer development timelines and rising costs due to the complexity of interfacing with other systems.
Vendor lock-in can also hinder innovation, as adding new components often requires adopting the vendor’s ecosystem, even if it does not fully meet the needs. This leads to license inflation and a heterogeneous portfolio of applications that is hard to maintain.
Open and Reversible Architectures
To avoid these pitfalls, prioritize modular, standardized solutions. A hybrid approach combining open-source building blocks with well-isolated proprietary components ensures an evolving platform while keeping license costs under control.
Comprehensive documentation of data flows, APIs and exchange formats is essential. It helps limit technological disruptions and facilitates switching to another provider or technology if needs evolve.
Reversibility can also rely on clear contracts: data portability clauses, source code delivery guarantees or split-billing provisions for licenses. This contractual transparency builds trust and commits the provider to long-term support.
Example of Technological Lock-In
A Swiss training organization had invested in a proprietary SaaS platform to manage registrations, billing and assessments. After two years, upgrade costs had tripled and adapting to new course curricula became prohibitive.
Migration to an open-source solution orchestrated by another provider proved complex because the data could not be exported in bulk. Several tables had to be recreated manually and billing processes rewritten.
This case illustrates that unanticipated vendor lock-in generates significant extra costs and undermines organizational agility. It also shows that implementing open standards and interchangeable formats is key to long-term autonomy.
{CTA_BANNER_BLOG_POST}
Rejecting Price-Focused Proposals
We refuse to sell projects based solely on price or billable-days. We favor a value-driven, governance-focused and sustainable approach.
Drawbacks of the Cost-Per-Day Model
A proposal based on the daily rate often conceals a project’s real complexity. It creates an illusion of budget control while generating hidden technical debt whose bill surfaces after kickoff.
Teams under pressure to stay within budget may be tempted to cut test coverage, skimp on documentation or favor ill-suited standard components. Ultimately, the software becomes costly to maintain and hard to evolve.
In a Swiss context where software-driven processes are often critical, this approach frequently backfires, generating hidden costs and extending deployment timelines for each new version.
Governance and Long-Term Vision
Rather than focusing on billable days, it’s better to clarify expected deliverables, success criteria and business milestones. This shared governance allows measuring the actual value produced at each stage.
Implementing indicators—time to production, number of incidents, adoption rate—makes project performance more transparent. It also encourages informed trade-offs between delivery speed and code quality.
A long-term vision includes planning for future evolutions and identifying consolidation points in advance. This limits the proliferation of disparate tools and maintains a coherent, enduring foundation.
Example of an Ill-Fitting Low-Cost Offer
A Swiss financial company chose the cheapest offer to overhaul its reporting module. Under time pressure, the developers delivered an “MVP” with no documentation or load testing.
Two months after go-live, the platform maxed out during a semi-annual closing period, causing delays of several days and regulatory penalties. Bringing it up to standard cost three times the initial budget.
This experience shows that an initially attractive price can lead to overruns and jeopardize the company’s compliance and reputation. It underscores the importance of a value-based proposal and comprehensive project governance.
Uncompromising Stand on Poorly Scoped Projects and Unrealistic Promises
We refuse to take on rushed projects based on vague assumptions and embellished pitches aimed solely at securing a signature.
Preventing Poorly Scoped Projects
Starting without a clear vision merely shifts risk rather than absorbing it. Unverified assumptions can lead to cascading change requests, lengthening timelines and increasing complexity.
To limit these deviations, an audit and prioritization phase is indispensable. It allows needs to be tested against real processes and identifies critical functionalities that justify early investment.
This step, often seen as an unnecessary cost, is actually a protective investment. It limits surprises and aligns expectations of business units, IT teams and the provider on a shared ground of truth.
Integrity in Communication and Realistic Promises
Software projects always involve uncertainties: validation timelines, integration complexity, regulatory or business changes. Hiding these uncertainties undermines mutual trust.
A clear and transparent discussion of risks, necessary trade-offs and available leeway fosters a sustainable partnership. It allows scope adjustments based on real constraints and anticipates potential bottlenecks.
Stating upfront what cannot be guaranteed—performance under heavy load, fixed deadlines without retrospection or exhaustive coverage without an appropriate budget—strengthens the relationship and avoids “broken promise” scenarios.
Technical Rigor and Critical Thinking
Being an agile provider doesn’t mean lacking rigor. Technology choices must be challenged based on context and risk. Adopting a methodology without critical thinking can lead to failure.
We believe a digital transformation project requires continuous dialogue, regular code reviews and honest progress checkpoints. Any deviation between requirement and implementation must be raised, documented and prioritized.
This demanding stance fosters a shared responsibility dynamic: each participant is encouraged to challenge decisions in the interest of quality, security and the solution’s longevity.
Example of an Abandoned Rigid Project
A cantonal administration had approved a monolithic architecture and an inflexible timeline. Despite technical warnings, the project began and accumulated delays.
Midway, the IT Director decided to halt the project due to lack of flexibility and identified security risks. Restarting required a full audit and technological reorientation toward a modular foundation.
This case shows that accepting a project without adaptability is more dangerous than suspending it right away. The timely halt avoided years of cost overruns and premature obsolescence.
Building Robust and Sustainable Software Projects
Turning down certain practices isn’t about rigidity, but about professional responsibility. By demanding an in-depth understanding of business challenges, ensuring technological independence, prioritizing value creation over cost alone, and maintaining transparent communication, we lay the foundation for enduring projects.
These requirements are the guarantee of adopted, scalable and secure software that supports the growth and agility of Swiss organizations. Our experts are at your disposal to assess your challenges, challenge your choices and guide you on the most suitable digital trajectory.















