Silesian SolutionsStart a conversation
All services

Services

Custom software

Building systems to order: web applications and PWAs, admin panels, B2B shops, portals and searchable catalogues. Maintenance and development after launch.

A yellow tape measure extended diagonally across a dark wooden table
Who it is for
Companies that need a system used every day
Scope
Web apps and PWAs, panels, B2B shops, portals
Outcome
Code, tests and documentation stay with the client
Principle
Only technologies already run in production

What the work covers

  • Process panel

    Cases, statuses, attachments, change history and role-based permissions.

  • Application in the browser

    A PWA that runs on a phone the same way it runs on a computer.

  • B2B shop

    Customer-specific prices, repeat orders, warehouse system integration.

  • Portal and searchable catalogue

    As much work on the data as on the interface.

  • Content pages

    A static generator where the content is the main material.

  • Integrations between systems

    REST and message queues.

  • Release in stages

    Every stage ends with a version that can be run and looked at.

  • Development after launch

    Fixes and further work within an agreed scope.

What gets built

We build the systems a company uses every day. The application is written from scratch and handed over with its code, tests and documentation.

A process panel gathers in one place what today is scattered across an inbox and a spreadsheet: cases, statuses and attachments, plus a change history and permissions that depend on a role.

Browser applications, shops and catalogues

An application that runs in the browser without installation works where the job happens in the field and an app store would be an obstacle.

A B2B shop follows a different logic from a retail one. Prices depend on the customer, orders repeat, and the integration with the warehouse system decides whether availability data is true.

A portal or a searchable catalogue is as much work on data as on the interface: where it comes from, how often it refreshes and what happens when a source falls silent.

How the technology is chosen

The technology is chosen for what the system has to do and for whoever will maintain it. The frontend is usually written in TypeScript with React or Angular, the backend on Node.js and NestJS, data goes to a relational database and content pages are built with a static generator. Only technologies we already run in production make the cut.

After launch, development and fixes continue within an agreed scope.

Tools and standards

  • TypeScript
  • Node.js
  • NestJS
  • React
  • Angular
  • Next.js
  • Astro
  • Vite
  • TypeORM
  • SQL
  • RabbitMQ
  • Progressive Web Apps

Proof: the deployments we describe

Each of these systems has a page of its own.

Panel
The claims-handling system for Best Assistance
Fieldwork
The same application as a PWA, with no install
B2B ordering
The WIR wholesaler, catalogue and orders from a spreadsheet

The system for Best Assistance was built for claims handling, and its PWA runs on a phone the same way it runs on a computer. The ordering portal for the WIR wholesaler was built in the B2B model. Cyber Katalog is a service about the cybersecurity market, built with the same method. Bezpieczne Bielsko-Biała is a public map of the city showing road distance to fire stations, shelters and iodine distribution points, with routes computed in the browser on a static page and no server of its own.

What changes once it is in place

  • The code, the tests and the documentation stay with the client, with no lock-in to one vendor
  • Every stage ends with a version that can be run and looked at, not with a progress deck
  • Scope and price agreed before the start
  • Only technologies already run in production, so maintenance is not an experiment

Typical use cases

  • A case-handling panel with roles, statuses and a change history
  • A PWA for fieldwork, running without an install from an app store
  • A B2B shop with customer-specific pricing and a warehouse system integration
  • A portal or catalogue with search, fed from external data sources

Questions that come up most often

What stays with the client after launch?

The code, the tests and the documentation, with no lock-in to one vendor. The application is written from scratch and handed over whole.

How is a panel different from a spreadsheet and an inbox?

It gathers cases, statuses, attachments, a change history and role-based permissions in one place. Today those things sit apart and nobody sees the whole.

When a browser application instead of an app-store one?

Where the job happens in the field and an app store would be an obstacle. A PWA runs on a phone the same way it runs on a computer, with no separate release per platform.

How is a B2B shop different from a retail one?

Prices depend on the customer, orders repeat, and the integration with the warehouse system decides whether availability data is true.

How is the technology chosen?

For what the system has to do and for whoever will maintain it. The frontend is written in TypeScript with React or Angular, the backend on Node.js and NestJS, and data goes to a relational database.

The other pillars