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 app development in GenevaYOUR CODE.YOUR FREEDOM.
Open-source plugins, utilities and applications: we build and integrate tools that you can inspect, adapt and develop further.
Let’s talk about your projectDirect answer · reviewed
Why build or integrate an open-source application?
Open-source software makes its behaviour, dependencies and licence inspectable before adoption. Navanem can build a plugin, utility, business interface or API, and can also assess an existing component to avoid unnecessary redevelopment. The decision depends on the problem, permissions, project maturity, community, maintenance and integration with your environment.
Open code does not guarantee security or compatibility; it enables deeper review and clearer responsibility. Our public projects demonstrate this approach through Payload Contact, Payload Comments, RoboSync and Leonida Atlas. For client work, we distinguish what can be reused, what needs adaptation and what deserves specific development, then prepare access, documentation and handover.
Last reviewed:
OPEN 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 differenceFREEDOM. 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 · Open-source appsFROM 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.
A first step to agree togetherSTART WITH SOMETHING CONCRETE.
Your starting point
The use case, software versions, integrations and data constraints. Where a repository exists, we also review its documentation and licence.
The first deliverable
Depending on the need: a compatibility review, focused prototype or first documented integration. The expected result is defined before development.
What we agree
Licence terms, relevant tests, documentation and maintenance responsibilities. Open code does not replace configuration or ongoing care of your installation.
Where we put it into practiceBUILT. NOT JUST TALKED ABOUT.
All projects
FAQ · Open-source appsTHE 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.