Загрузка…
A list of technologies is easy to copy and means nothing on its own. So this page also gives the reasons behind the choices and what gets built with them.
Before a technology goes into a client's project, we wait for it to run in production elsewhere for a few years. Experiments with new tools are always paid for by the client, so we do not run them.
Any project of ours moves to another server, another cloud or the company's own hardware. If a system cannot be taken away, the contractor was solving their problem, not yours.
Sooner or later another team will take the project over, and that is fine. We write so that a new person finds their way without us and without a month of handover.
For every technology in the registry there are developers available to hire. A rare stack known to a few dozen people leaves you with one contractor and their prices.
The list holds only what has already run in delivered projects. We do not give version numbers: they change faster than this page does.
Everything the user sees and clicks. If this part is awkward, people go back to spreadsheets no matter how sound the system is underneath.
Primary language of the interface
Used inEvery project: strict types catch errors before production
The base language of the web
Used inScripts, widgets, changes to code we did not write
Interface library
Used inCustomer portals, admin panels, internal systems
Application framework and server rendering
Used inSites and services that need to rank in search
Layout and responsive design without off-the-shelf themes
Used inInterfaces built to the client's own brand
State management for large applications
Used inSystems with dozens of screens over shared data
State management where simpler and faster is enough
Used inMid-sized portals and admin panels
Interface tests in a real browser
Used inChecking payment and checkout before a release
Tests for logic and calculations
Used inFormulas, form validation, data processing
This is where money is counted, access rights are checked and the company's rules live. A mistake here does not spoil the look of a screen: it charges the wrong amount.
Primary server runtime
Used inWeb application APIs and data exchange services
Fast web server on Node.js
Used inHigh-load APIs with hard latency requirements
Second server language: data and AI
Used inDocument parsing, data exports, AI services
Web layer for Python services
Used inInternal services and AI endpoints
Message queue between services
Used inData exchange that must survive a failure
Background and scheduled jobs
Used inOvernight exports, reconciliations, mailings, heavy reports
Event streaming at high volume
Used inIntegrations where data arrives as a continuous stream
An application can be rewritten in a couple of months. Lost data is gone for good, which is why we pick this layer more carefully than any other.
Primary database
Used inOperations, orders, documents, financial transactions
Database for loosely structured data
Used inLogs, product records, change history
Cache, sessions and queues
Used inTaking load off the database at peak hours
Database for analytics at high volume
Used inReports and dashboards over millions of rows
Full-text search
Used inSearch across catalogues and document archives
File storage on your own server
Used inDocuments and media without handing them to someone else's cloud
The most common request from mid-sized businesses: 1C, the CRM, the site and the warehouse cannot see each other, so someone moves the data by hand. This layer takes the person out of the middle. Listed below is what we have already connected; the protocols at the end of the list answer the question about everything else.
Exchange with the company's accounting system
Used inProduct catalogue, stock, orders, mutual settlements
CRM exchange: deals, contacts, tasks
Used inSite enquiries land in the pipeline with no manual entry
Exchange with the sales team's CRM
Used inDeals, statuses, automatic tasks for managers
Warehouse and trade operations
Used inStock and orders across warehouse, site and till
Taking payments on the site
Used inOrder and subscription payments, refunds, receipts
Taking payments from abroad
Used inProjects billing customers in other countries
Statements and payment orders
Used inIncoming payments reconciled without an accountant
Marketplace APIs
Used inUnit economics and price control across four marketplaces
Orders, quotes and position state
Used inTrading bot and P2P monitoring on Bybit
Bots and mini apps
Used inEnquiries, notifications, internal team tools
Messages and notifications to customers
Used inOrder statuses and mailings beyond Telegram
Connecting an existing site to the back office
Used inShops that do not need rebuilding from scratch
Store on an international platform
Used inProducts and orders exchanged with internal systems
Analytics and goal tracking
Used inEnd-to-end funnel: from visit to deal in the CRM
Standard exchange protocols
Used inConnecting to any system that exposes an API
Exchange where no ready API exists
Used inCSV and XML exports, FTP, email, scheduled SFTP
Not chat for the sake of chat, but parsing documents, searching the knowledge base and offering suggestions inside the working screen. From our own experience: the UFound platform.
General-purpose model for text and dialogue
Used inFirst-pass handling of enquiries and in-interface suggestions
Working with documents and long text
Used inExtracting data from contracts and invoices
Reading images and scans
Used inRecognising documents and photos from the shop floor
Low-cost model for high-volume tasks
Used inBulk processing where the price per request matters
Multi-step scenarios
Used inTasks where a single model call is not enough
Search by meaning rather than by words
Used inSearch across the knowledge base and company archive
What separates a delivered project from a working one. This layer answers whether the system will survive its first year after launch.
Packaging services into containers
Used inEvery project: the same environment everywhere
Running services under load
Used inSystems that cannot afford downtime
Describing and versioning what ships to the cluster
Used inIdentical deployment on staging and in production
Service-to-service networking: routing, encryption, retries
Used inClusters with many services calling each other
Issuing and renewing TLS certificates
Used inHTTPS that does not expire because someone forgot
Storing passwords, keys and tokens
Used inCredentials that must never sit in code or config files
Rolling out updates from the repository
Used inReleases without manual commands on the server
Infrastructure described as code
Used inRepeatable deployment into the client's own cloud
Builds and tests on every commit
Used inChecking code before it reaches users
Load balancing, routing, HTTPS
Used inThe entry layer of every project
Server operating system
Used inServer setup and ongoing maintenance
Without monitoring, it is the client's own customer who reports the outage. We put this layer in from the start, not after the first incident.
Collecting metrics and firing alerts
Used inWatching the health of services and the database
Dashboards on system health
Used inDashboards for us and for the client's own IT team
Storing logs and searching them
Used inIncident analysis: what happened, and when
Shipping logs from servers into Loki
Used inLogs from every service collected in one place
One standard for metrics, logs and traces
Used inThe full path of a request across every service
Viewing request traces
Used inFinding the exact step where things slow down
A client does not need a database, they need a system that solves a problem. Here is what the stack above turns into.
The problem comes first, along with whatever already works at your company. Technology after that. The first conversation commits you to nothing.