/technologie
Technologie, w których pracujemy
Technologia jest narzędziem, nie celem projektu. Poniżej pełny stack, z którego korzystamy — i uczciwa informacja o tym, gdzie mamy największe doświadczenie, a gdzie pracujemy rzadziej.
Backend rdzeń
- PHP 8.x
- Laravel
- Symfony
- Slim
- Node.js
- Express
- NestJS
- Python
- FastAPI
- Django
- Go
Tu jest nasze centrum ciężkości. Logika biznesowa, integracje i wydajność decydują o tym, czy system wytrzyma trzeci rok pracy.
Bazy danych rdzeń
- MySQL
- PostgreSQL
- MariaDB
- Redis
- MongoDB
- Elasticsearch
- SQLite
Model danych to najtrwalsza część systemu — kod da się przepisać, źle zaprojektowanej bazy się nie naprawia bez migracji.
API i wymiana danych rdzeń
- REST API
- GraphQL
- WebSocket
- Webhooks
- OAuth 2.0
- JWT
- OpenAPI
- SOAP
- RabbitMQ
Standardy, w których udostępniamy i konsumujemy dane — wraz z uwierzytelnianiem i dokumentacją.
Frontend
- JavaScript
- TypeScript
- Vue.js
- Nuxt
- React
- Next.js
- Alpine.js
- Livewire
- Tailwind CSS
- Bootstrap
- HTML5
- CSS3
Interfejs dobieramy do skali. Nie każdy panel potrzebuje frameworka SPA — czasem lepiej sprawdza się lżejsze podejście.
DevOps
- Docker
- Docker Compose
- Kubernetes
- Linux
- Nginx
- Apache
- Traefik
- Git
- GitHub Actions
- GitLab CI/CD
- Terraform
- Ansible
Powtarzalne środowiska i wdrożenia bez ręcznego kopiowania plików na serwer.
Chmura i infrastruktura
- AWS
- Google Cloud
- Microsoft Azure
- Cloudflare
- DigitalOcean
- Hetzner
- S3
Hosting dobrany do realnego ruchu i budżetu — od pojedynczego VPS do środowiska rozproszonego.
Architektura
- Monolit modularny
- Mikroserwisy
- DDD
- CQRS
- Event-Driven
- Clean Architecture
- Repository
- Kolejki zadań
Wzorce stosujemy wtedy, gdy rozwiązują konkretny problem, a nie żeby projekt brzmiał nowocześniej.
Jakość i bezpieczeństwo
- PHPUnit
- Pest
- PHPStan
- Psalm
- Code review
- OWASP Top 10
- Sentry
- Monitoring
- Kopie zapasowe
Elementy, które nie są widoczne w demie, ale decydują o kosztach utrzymania.
Sztuczna inteligencja rdzeń
- OpenAI GPT
- ChatGPT
- Google Gemini
- Anthropic Claude
- Wyszukiwanie wektorowe
- Osadzenia (embeddings)
- RAG
- Strumieniowanie SSE
- Walidacja odpowiedzi
Modele językowe wpinamy w istniejący proces przez warstwę pośrednią, żeby zmiana dostawcy nie oznaczała przepisywania aplikacji. Odpowiedzi weryfikujemy schematem, a decyzje nieodwracalne zostawiamy człowiekowi.
Wdrożone integracje rdzeń
- InPost
- Paxy
- Olza Logistic
- DHL
- Poczta Polska
- ID Logistics
- ROHLIG SUUS Logistics
- Blik
- PayU
- Tpay
- PayPal
- Swish
- MobilePay
- iDEAL
- Bancontact
- Apple Pay
- Google Pay
- Montonio
- Subiekt GT
- Enova 365
- Comarch ERP
- Symfonia
- NASK
- EuroDNS
Systemy, które realnie podłączaliśmy — wdrożenie idzie szybciej, bo znamy ich ograniczenia i miejsca, w których się psują. Pełne opisy w zakładce Realizacje.
/decyzje
Jak wybieramy stack do projektu
Cztery pytania, które zadajemy przed napisaniem pierwszej linii kodu. Odpowiedzi na nie znaczą więcej niż moda na konkretny framework.
Kto będzie to utrzymywał za trzy lata?
Jeśli projekt ma przejąć Twój zespół albo inny wykonawca, wybieramy technologię z dużym rynkiem specjalistów. Egzotyczny framework potrafi być technicznie lepszy i biznesowo katastrofalny.
Jaka jest realna skala?
Aplikacja dla trzydziestu osób w firmie i platforma z dziesiątkami tysięcy użytkowników to dwie różne architektury. Budowanie mikroserwisów „na wyrost" podnosi koszt i czas wdrożenia bez żadnego zysku.
Co już macie?
Jeśli firma pracuje na PHP i MySQL, dopisanie modułu w Go dla jednej funkcji oznacza drugi zestaw kompetencji do utrzymania. Nowa technologia wchodzi tylko wtedy, gdy rozwiązuje problem, którego obecna nie rozwiązuje.
Gdzie to będzie hostowane?
Budżet na infrastrukturę wpływa na wybór stacku równie mocno jak wymagania funkcjonalne. Kubernetes na trzech kontenerach to koszt bez korzyści — pojedynczy serwer z Dockerem wystarcza w większości projektów.
Nasze domyślne wybory
Gdy nic nie narzuca innej ścieżki, sięgamy po PHP 8 z Laravelem lub Symfony, PostgreSQL albo MySQL, Redis do cache i kolejek oraz Docker do środowisk. Frontend zależy od charakteru interfejsu: panel administracyjny często szybciej powstaje na Alpine.js i Tailwindzie, a rozbudowana aplikacja użytkownika na Vue lub React.
To nie dogmat. Jeśli projekt wymaga przetwarzania strumieniowego, wysokiej współbieżności albo integracji z konkretnym ekosystemem — proponujemy narzędzie właściwe dla zadania i mówimy wprost, jakie to niesie konsekwencje w utrzymaniu.
/kontakt
Opisz problem.
Odpowiemy, jak go rozwiązać.
Krótka rozmowa wystarczy, żeby ocenić zakres, technologię i realny termin. Bez zobowiązań i bez ofert na 40 stron.