we work

tech stack, methodology, processes

E-commerce Software Development

Our primary business domain is E-commerce.
That means any site that directly sells either physical or digital goods.

We have experience with building and maintaining:

  • Single sales pages,
  • Classic, cart-based webshops,
  • Subscription based solutions,
  • Custom search and filtering,
  • Online payments (Braintree, Stripe, Paypal, PayU, OTP (hu), Mobilpay (ro), Euplatesc (ro)),
  • Order processing,
  • Courier integration (DPD, Fancurier (ro), Sprinter (hu)),
  • Automated billing,
  • Multiple currencies and languages,
  • EU VAT calculation,
  • Data interchange with ERP and accounting systems,
  • CRM,
  • High-traffic websites.

tech stack

tl;dr: See on stackshare.

We pretty much cover the full stack web developer definition. However if we must highlight our most powerful areas, they're PHP Backend development and simple but scalable Cloud Infrastructure.

Web Applications

Currently we have active projects with:

  • PHP 7.0 - 8.1 🐘
  • nodejs + typescript + express + fastify
  • Swagger (OpenAPI 3)
  • Symfony 2 - 5
  • Laravel 6 - 8
  • Sylius 0.14 - 0.17, 1.0
  • Phalcon 2 - 4
  • WordPress + WooCommerce

We use these technologies to create websites/applications, REST APIs, CLI apps, background jobs.

Formerly we also used to work with:

  • Yii 1, 2
  • Magento 1 ⛈
  • Zend Framework 2
  • Konekt Framework 1, 2 (our own MVC 🤦)


Our typical solution can probably be best described as Hexagonal Architecture + Domain Events.

So you won't see fat controllers or god objects. We have to admit fat services are still alive in some of our older codebase As of 2022 all fat services are gone 🌈.

We've been having flirts with CQRS for a while and lately also with Event Sourcing.


  • vuejs
  • alpine.js
  • react
  • sass
  • webpack / encore / mix
  • bootstrap 4-5
  • tailwind


  • AWS: EC2, S3, SQS, SNS, Cloud Formation, Data Lakes
  • Digital Ocean (droplets, storage, spaces, load balancers, DB)
  • Google Cloud: Firebase, Data Studio
  • Docker, Nginx, php-fpm, Varnish
  • MySQL, Postgres, Redis, MongoDB
  • Mailgun, Sendgrid, Postmark
  • Other CDNs like Cloudinary


  • Travis, StyleCI, Scrutinizer
  • Github Actions, Bitbucket Pipelines, Gitlab CI
  • Postman + Newman
We deploy with CF, DeployBot and Envoyer. Anytime.


  • Pingdom, UptimeRobot
  • Datadog, NewRelic
  • OpsGenie, PagerDuty
  • Cloudwatch
  • Blackfire


Yes, we've been hacked already. And had to write a post-mortem report to a Police Investigator once. That's why we use:
  • Cloudflare
  • Nexpose
  • Rigid non-access policy on servers
  • Key based authentication if possible
  • Double encrypted password store
It's worth to mention that we're not security experts. We've found that's a separate profession.



We usually don't take fixed price projects, but prefer long term, permanent relationships.

The reasons why we're concerned:

  1. At the beginning of the project none of the parties exactly know what they're about to build.
  2. Parties often think they do know, but they actually don't.
  3. Repeat: at the beginning there are many factors unknown for either of the parties.
  4. If we jump on the train of very-very detailed specs, it takes an extended period and it is still unable to predict the future.
  5. If we overestimate, the client pays more than it costs.
  6. If we underestimate, we loose money.
  7. If the client pays more, they try to squeeze out more than that was in the agreement.
  8. If we loose money, we'll try to minimize further loss by chopping off features/quality.
  9. Any of these scenarios results either a win-loose or a loose-loose situation.
  10. This also leads to shameful negotiations.

Related read: scope creep.

What we've seen to work very well during the years and proved to be very efficient is to work very close together as we were part of the internal team. Most successful projects we've participated worked this way.

We are more than open to discuss your next project idea, and provide with an insight of what to expect, an estimated timeline, possible obstacles and solutions.


Our preferred way to work is billing per hour.

It means we log all our activities in JIRA. Logging only happens when we're actually working with something, so it's expected to have ~6 hours/person/day (with a full time contract).

At the end of the month you'll receive a detailed Time Report that contains all the work done and the number of hours spent with them. We don't do rounding, so 30 minutes of work is always 0.5 hours


Our team currently consists of 7 people.


Normal business hours are 9:00 - 17:00 EET.
Live systems are being monitored and recovered on failure 24/7/365.
We operate a helpdesk for projects in the operation/maintenance phase.

We can provide with services beyond business hours/days on demand.


Apart from being a buzzword, Scrum can work pretty well in some scenarios.
We can do Scrum if necessary, but we don't stick to it.

We've done dozens of sprints already with all those goodies like planning poker (fun), burndown charts (never worked), dailies, grooming, planning and retros ¯\_(ツ)_/¯.
If the decision is up to us, we choose a workflow that's near to Kanban, with rapid 1-2 weeks iteration + continuous delivery.

There's one thing we encourage as much as possible, and that's a clean agreement on:
- who can submit requests,
- what are the expected results,
- who/when approves completed work,
- complaint resolution paths.


Our default work language is English.
We also speak: Hungarian, Romanian, German, Russian (and one of us can read Dutch 😉).

We create ALL WRITTEN MATERIALS like worklogs, code, comments and documentation exclusively in English.

Feels like we could work together?

Take a look at our job openings