AROBS Transilvania Software

Request info

The AROBS Pricing Policy


How would you describe the value/price ratio for your services?


Some of our customers had been paying Indian companies about half of our rates prior to switching to AROBS. Unsurprisingly, they are much happier with the value/price ratio they are getting from AROBS than with those from our Indian counterparts. We rely on talented and hard working developers, who are producing accurate code quite fast.

What are the driving factors of your prices?


Contract length, team size, project continuity (the fewer the slack times between projects the better the rates), the level of expertise required, the team structure, the ramp-up model (the slower the change in structure, the better for us) are the most important factors that drive our rates.

What pricing models are you using?


We prefer the time and materials approach, since specifications are rarely precise enough to justify using the fixed pricing model. Furthermore, we have almost never dealt with specifications that suffered no change throughout the project lifetime.

Do you accept to work on a fixed price model?


We do fixed pricing based on clear specifications. When the Scrum methodology is applied, we prefer to stay away from fixed pricing, unless we are guaranteed that specifications will not undergo major changes. Any time we do fixed pricing we expect change requests from the customers whenever changes with an impact on our effort are needed. Based on the request we will redo the quote. Whenever the customer doesn't have an exact picture of what he wants we prefer to work on a time and material basis.

How long are your rates valid?


We only make rate adjustments at the beginning of the calendar year. For any project that is completed in a single calendar year the rates initially agreed upon remain unchanged.

Do you offer discounts from your standard rates?


Long term projects reduce our costs and risks, making them the main candidate for discounting.Gaps between projects that leave developers without paid work bring us significant losses. Companies that book resources permanently get the best rates.Gradual ramp-ups can also bring discounts. It is significantly easier for us to assign 2 developers to a 1 year project that 6 developers to a 4 month project. If we only have 2 developers readily available out of the 6 required for the project, we must bring new people on board, without any guarantee there will be any work for the newcomers when the project ends. If the project team is increased slowly, we usually have enough time to find new customers and thus minimize the risk of significantly (and abruptly) increasing the number of developers not involved in paid projects.Change forecasts for your resource requirements, provided a few months in advance, are also very helpful.