Code flow


From the very beginning we organized our repositories to match the code flow. We use two main branches (master and development) and a few other for features, fixes and bugs. We use the master branch as reflection of production code, and development for staging purposes. For every new feature and bug fix we create a new branch, connect it to a backlog item and monitor the progress at all times. We use naming which allows us to easily distinguish between branches and their purposes. We also tag important milestones to match their releases.

479b9b2 Initial commit - aveneo <> 12349fb Add TypeScript - aveneo <> cc7789e Make it work. - aveneo <> b0f3479 Make it right. - aveneo <> 5bc0361 Make it fast. - aveneo <> features/feature-579_add-typescript 95365bc Merge branch features/feature-579_add-typescript - aveneo <> f6c03da Fix it. - aveneo <> bugs/bug-127_loader e4cae17 Merge branch bugs/bug-127_loader - aveneo <> 09b85ea Prepare v1 - aveneo <> development 8e7fe48 Merge branch development - aveneo <> master v1.0.0



While we use different IDE and text editors we strongly standarized coding. Following internal rules of casing, formatting, code reusing, code structure, architecture, files organization allows us create uniform sources for every project. We use mainly two different aproches for development depending on needs - FDD (feature driven development) or TDD (test driven development). We also aim at strong design patterns. At the end of the day code is refactored & linted for streamline and optimized shape matching our strong standards and all needs of solution.

Visual Studio Logo
Visual Studio
VS Code Logo
VS Code
Visual Studio for mac Logo
Visual Studio for mac
JetBrains Rider Logo
JetBrains Rider
Vim Logo
Notepad Logo

Pull requests & code review

Every line of code that we want to add to development and master branch is checked twice. We use cross-review of developers. We look for all kinds of problems in code - from architecture, through structure, bad patterns and naming convention to formatting or casting mistakes. This method allows us to catch potential dangers on the development level and optimize code therefore making it safer before we even get to the testing stage. Sometimes we need to rethink an idea, revert changes and abandon a pull request. It happens, but it’s better to take a minute and review rather than have issues on production.

Multilevel verification
No unresolved comments
Minimum of two reviewers
Pull requests & code review


The last - but by no means least important - step is testing. During the development process all of our code needs to pass through unit and integration tests. Only then, after merging to development, we test it using automated scenarios and using manual tests. If everything goes fluently we are ready to merge the code into the production branch and create a second pull request resulting in code review and unit and integration tests from many feature branches.



For each project we create fully automated deployments and continoues integrations (thanks to Azure Pipelines and Azure Artifacts). From 2019 we deploy every single one of our solutions in container model - ready for Docker and Kubernetes.

Are you ready to talk about your project?
  • If you only know the need or problem to be addressed by the software, are you able to help?

    Our primary goal is not so much to provide software, but to actually address the needs and solve problems of our customers. Before we start creating a vision of the software's functionality together, we will conduct a deep analysis to reveal the needs. We will then prioritize them based on business values. We will also look for paths to optimize the operation of your business processes, not only from the perspective of the software itself.

  • I am afraid of problems when creating software resulting from my lack of substantive knowledge about this process. Is it right?

    For us, the key value in working with non-technology-savvy clients is to bring them as close to technology as possible. That's why we devote a lot of time and attention to carefully explaining each stage of the software development process. We also provide advice so that design decisions are fully conscious and based on understandable values.

  • I don't know how to manage the budget for software development. What to do?

    Many clients are afraid of disclosing the budget at the early stage of the project, believing that it will negatively affect the valuation of the project. This is the most common mistake and cause of frustration in the software development process. Really defining the budget allows you to look at functional needs from many perspectives. Being aware of the limited budget, we can look for more economical solutions that may not be fully satisfactory, but at this stage they will address the needs and will be sufficient. As the business value of the entire project increases, these areas may be developed, but this does not have to happen immediately. There are several proven solutions that allow for controlled budget management - we will present them and help you with this task as soon as we get to know each other.

  • Will software development using the agile methodology cause delays, blurred goals and increased costs?

    This is one of the most common concerns that arises at the early stage of talks about implementing a new project. In short: no. An agile approach to a project does not preclude setting clear goals and points on the timeline that are to be achieved. However, frequent and small design iterations allow you to obtain the desired functionalities faster with a reduced budget. The combination of lean development with continuous validation of requirements and assumptions perfectly verifies the previous needs analysis. In fact, the analysis progresses with the development of the project and naturally optimizes its scope by limiting unnecessary steps.

  • How do I know if you are technologically capable of working on my project?

    If our portfolio is not enough of an argument, we will be happy to present technological possibilities and talk about the challenges we have encountered over the years of working on other projects and how we found solutions to seemingly unsolvable problems.

  • What should our communication look like during the project?

    In communication with clients, we focus primarily on honesty, openness and transparency. This allows you to avoid understatements while building lasting, mutual trust.

  • How can we manage the project schedule so that it doesn't stretch over time?

    We look at each project on two scales - micro and macro. On a macro scale, we define milestones for modules and functional areas that we want to achieve in specific order and points on the project timeline. On a micro scale, we manage tasks in iterations no longer than 2 weeks, so we have full control over the implementation stage and can dynamically respond to emerging threats by e.g. increasing internal resources.

  • What if my users don't want to use the software we created together, or don't do it as intended?

    Implementation is not the last stage of the software development cycle at aveneo. We help with user training and training. We are the best partner for this because we know all the design assumptions and full mechanics of the delivered solution. This will guarantee satisfaction and understanding of the solution, and will also allow you to collect conclusions from users regarding potential optimizations and new functionalities.

  • How to reconcile the many different roles of software users without internal contradictions?

    For large projects, it is difficult to bring all stakeholders together at every meeting. It is completely natural for different departments to have mutually exclusive expectations. Our role is to collect all the needs and design a solution that will take into account all business processes and reconcile those that stand in opposition to each other into a coherent and logical whole.

  • I have serious concerns about whether the project will ultimately succeed. How to deal with it?

    This is completely normal! Every investment carries some risk. Depending on the source of the concern, additional levels of security should be implemented. For our part, we will try to find tools that will help you get rid of stress and guarantee the success of the project. For example, if concerns concern the functional scope, we suggest identifying the most valuable functionalities and building a small section of the software, and then validating the assumptions and checking in a real environment whether the solution is satisfactory.