Web & business applications
An application begins with tasks, roles and data. We design direct journeys instead of reproducing a complicated process on screen. Whether code will be published is considered alongside scope and associated rights.
03 / Open-source applications · Switzerland
YOUR CODE.YOUR FREEDOM.
Open code creates possibilities. A useful, understandable and maintainable tool makes them real.
Let’s talk about your projectOPEN BY CONVICTION.
We develop applications and components for concrete needs: organising enquiries, hosting discussions, exploring a map or simplifying an IT operation. Our Navanem.com lab provides access to several of these projects. For a business in Geneva, Lausanne or French-speaking Switzerland, the challenge is the same: understand the tool, integrate it into its environment and plan its future. We assess what already exists before deciding what deserves new development.
Desktop software
Some tasks require access to files, an operating system or a local tool. Desktop software can be the appropriate choice. RoboSync illustrates this approach with Robocopy settings and execution in a Windows environment.
Plugins & extensions
A CMS or platform may already cover most requirements. A plugin adds a missing function without rebuilding everything. Payload Contact and Payload Comments address different needs: receiving enquiries and organising discussions beneath content.
APIs & automation
Connecting tools can reduce repeated entry and improve data exchanges. We define source data, permissions, error handling and recovery. An automation should remain understandable to the people who depend on it.
Integration & adaptation
We examine documentation, licensing, project activity and dependencies. The aim is to understand what fits, what needs adaptation and which constraints will remain. Open software is not automatically the best choice for every task.
Documentation & handover
Installation, configuration, limitations and routine operations should be explicit. Documentation supports future changes and handover to another team. Access credentials and private data are kept separate from publishable material.
What makes the difference
FREEDOM. WITH A METHOD.
Accessible code offers opportunities to inspect, adapt and contribute. To make them useful, we also examine obligations, running costs and the ability to maintain the project.
Make an informed choice
We compare features, integration constraints and maintenance effort. Existing software may be adaptable; custom work may be justified. The decision should be explainable, considering total cost rather than just an initial price.
Make handover possible
Another team should be able to understand the essential decisions. Reproducible setup, documented configuration and identified dependencies reduce uncertainty. Independence depends on handover as well as repository access.
Plan the software’s life
Updates, backups, monitoring and fixes need an owner. Maintenance scope is agreed with the project. Open code does not replace that work or mean all future changes are included.
How we move forward
FROM IDEA TO REALITY.
Define the need
We describe users, operations to simplify and data constraints. The intended outcome should be verifiable through a concrete use case.
Assess existing options
We examine useful components, their licences, compatibility and upkeep. Reuse is a technical decision, not an automatic rule.
Build & integrate
We implement the agreed scope with input validation, access controls and checks on important journeys. Integrations are tested in context.
Document & support
Instructions, responsibilities and conditions for future work are handed over. Teams need to know how to operate the tool and where to turn when needed.
THE RIGHT
QUESTIONS.
Does open source mean free?
No. A licence defines rights to the code under its conditions. Design, integration, hosting, support and maintenance may carry costs. We separate software, operations and support so the project cost is understandable.
Does our business code have to become public?
That depends on the project and its licences. Publication scope, confidential elements and redistribution obligations must be considered before choosing components. Private data and access keys never belong in a public repository.
Can we commercialise a SaaS application?
Yes, a SaaS business can use open components while respecting their licences. Accounts, permissions, billing, hosting, support and operations also need planning. Our Suniworks ecosystem supports business applications and SaaS products.
Is open code automatically secure?
No. Availability allows inspection but does not constitute an audit. We implement relevant controls and review dependencies, permissions and updates. Additional requirements need to reflect the project’s data and risks.
What happens after delivery?
We define documentation, responsibilities and maintenance options. A repository alone is not enough: your team needs to understand routine operations, limitations and updates. Future improvements can then be prioritised from observed needs.