Setics

Setics is a Toulouse company that publishes fibre-network design software. Joined in October 2023, after a six-month final-year internship in Germany. Since then, day-to-day development of the portfolio and de facto technical lead: daily code review, including the contractors’ changes, architecture decisions, coordination of an external contractor on the integration of a mapping plugin, customer demonstrations in English.

Sttar

The main product is Sttar: a C#, .NET and WPF application for automated FTTH network design, over five hundred thousand lines at solution scale, generated UI code included, deployed by telecom operators in Europe, the United States and Asia. That is where most of the time goes.

Main algorithm made modular. It used to run as a single block; it is now cut into steps that can be enabled separately: routing, cabling, node placement, service areas, infrastructure design, fibre connectivity. Users choose what they re-run instead of replaying everything.

Performance, mostly off the roadmap. Map selection went from several minutes to a few seconds on the measured datasets, records kept; the optimisation pipeline behind it relies on case-based reasoning and a Delaunay triangulation. Service-area loading moved from DotSpatial to GDAL. The routing engine was rewritten from about two thousand lines down to thirteen hundred, and the hand-coded special cases in duct merging were replaced by a cost model.

Interface redone for version 2.5, with the goal of making the product usable without the documentation open alongside: icons redrawn, visual language harmonised in one pass. User documentation left Manula, internal documentation of the codebase keeps itself current, and a tool diffs two versions to produce the release notes.

Build and test chain. Maintenance of the Azure Pipelines behind Sttar and clearance of a long tail of build and test failures. The SaaS products started since then run on the same regime: tests on every change, continuous integration, semi-automatic deployment.

Mapping plugin, followed end to end: ArcGIS Pro implementation brought back in-house, two other internal plugins merged into it, port to QGIS in progress; more below, under GIS tooling.

On top of that, bug fixes, easily half of what gets shipped.

SaaS products

Three sold products, whose roadmap the company decides and whose technical choices sit with the position: a clear boundary with the internal tools below.

FiberState (TypeScript, React, .NET, Azure) tracks fibre deployment in the field. Current work is on the layer above it: a native physical inventory of the network, with site management driven from the map. Three problems are interesting there: dependency scheduling, where a task that slips propagates its delay through the whole plan; a field application designed offline-first, because a work site has no network at the exact moment it needs one; and the reconciliation of as-built data into the reference inventory, that is, the gap between what was planned and what was actually installed.

STEM (NestJS, Next.js, Cosmos DB) is a multi-tenant platform whose API and frontend are deployed as separate services on Azure App Service. The most recent work on it was done here, with occasional contributions from a colleague.

Network monitoring, on the same stack, sold as a service: it watches the networks the two previous products have planned and then built. Development carried after a first version delivered with a contractor.

The three chain together, and that is what makes the work interesting: plan the network, track its construction, then monitor it once it is running. The same business objects cross all three products, and most of the work consists in getting them through without being redefined at each boundary.

Internal web apps

Take an internal flow scattered across a spreadsheet, a ticket queue and an email loop, and replace it with an application. None of these three tools was on the schedule: proposed, stack chosen, written alongside the rest of Sttar.

Licensing chain (.NET, Blazor Server, EF Core, Azure SQL), rebuilt from scratch to automate the journey: request filed by the customer on the portal, quote pre-filled from templates and offers, commercial validation (which a human always approves), then automatic generation and delivery of the licence. It replaces a database kept in a spreadsheet, a ticket queue and email exchanges with a single source of truth. Operating Sttar’s licences is part of the scope.

Unified portal: access to the software, documentation and customer-side licence management, plus the internal back office, all in one place. Blazor Server with single sign-on; that authentication chain is the current work.

Internal assistants: a prototype for Microsoft Teams, in TypeScript, multi-agent on Claude, with retrieval-augmented search and the Graph API. The idea: a colleague asks how the product does something, and the answer comes from the internal documentation rather than from a model making things up. The planned next step is the same assistant for customers, inside the product, then able to act there on their behalf.

GIS tooling

Two mapping applications, two imposed extension languages, and the same business logic to run in both, the plugin mentioned above under Sttar. The lazy solution is to write the logic twice and watch it diverge at the first fix.

Here the exchange boundary is WKB, and the computation core depends only on shapely and networkx, not geopandas, not qgis, not arcpy. It does not know which host it runs in, which is the point: a business-logic fix lands everywhere instead of being written twice.

The QGIS plugin covers QGIS 3 and QGIS 4 from a single release; that is where, and only where, a single deliverable serves two versions. The unified ArcGIS add-in is specified, not built.

The ArcGIS Pro implementation was first brought back in-house, then two other internal plugins were merged into it, and that result is what is being ported to QGIS. The business logic comes with it: link budgets, optical path reports, splice management, fibre line serialisation, attribute mapping, spatial reference systems.

This page does not say what these products and tools do for whom: customers are not a portfolio argument.

This job is where architecture, code review and customer relationships were learned.