An engineering company that builds software in Istanbul

It depends on the scope. For a web or mobile application that has been clearly defined, we ship the first usable version in 6 to 10 weeks on most projects. On a smaller build that solves one workflow, that comes down to 3 to 4 weeks.

The difference comes less from development speed than from how clearly the work was defined before it started. So the first stage is deciding together on the screens, the core business rules, the integrations, and the features the first version will leave out.

During development we hand over a working version every two weeks. For the parts every product needs, authentication, notifications, payments, and an admin panel, we use mature libraries and existing services where they fit.

The team is in Istanbul, so discovery and project meetings can happen face to face when that is easier.

On marketing automation projects the first job is usually getting the tools the company already runs to talk to each other properly. Building something new from nothing comes after that.

We build data flows between the CRM, the email and SMS services, the ad platforms, the e-commerce side, and the ERP. Something a visitor does on the site can update their record in the CRM. Particular behaviour can open a sales task or move the person into a different message sequence.

We work with HubSpot, Salesforce, Pipedrive, Mailchimp, Klaviyo, Google Ads, and Meta. We also build integrations with local services that offer an API.

Most of the work sits around connecting the APIs rather than in the connection itself. Field mapping, retrying failed operations, stopping the same operation running twice, error tracking, and the consent records that are required are all part of the system.

If an existing product covers the need, we set that up. Where off-the-shelf tools fall short, we build the integration or automation layer in between.

On a tight budget we do not shrink the idea. We shrink the problem the first version has to solve.

Rather than automating ten workflows at once, we pick the one that wastes the most time or earns money directly. The first phase makes that one work end to end. Once the product is genuinely being used, the rest go in one at a time.

Which parts have to be custom built also drives the cost. If a reliable existing service already solves the problem, writing the same system again has no point. We size the infrastructure to what the product needs today.

There is no harm in telling us your budget up front. We will say plainly what fits inside a given figure and what has to wait for the next phase.

Start with whether you are meeting the people who will actually work on the project. If you will never see the people from the first meeting again once development starts, it gets hard to tell how much of what was promised will reach the code.

Ask before signing who will control the source code, the cloud accounts, the domains, the databases, and the other accounts opened for the project. Starting that conversation after the project ends creates a problem neither side needs.

What happens after launch is its own subject. Who handles error tracking, updates, and the infrastructure should be settled at the start.

Find out how often you will see the product during development. A presentation or a status report does not show where a project stands. A running version does.

At Intellego the client works with the technical team directly throughout. We keep the source code and, wherever possible, the project infrastructure in accounts the client controls, and we hand over a working version every two weeks.

Two applications that look alike can cost very different amounts to build. The reason is usually not the number of screens but the business rules behind them and how much the system has to talk to other services.

A simple admin panel and an application with several user roles, approval flows, payment systems, an ERP integration, and automated notifications can look similar from outside. The development load is not the same.

So before quoting we work out the main user flows, the integrations, and the permission structure. The data model and what you expect operationally after launch are part of that conversation too.

Where the scope is clear enough, we work to a fixed scope and a fixed price. If the product is expected to take shape during development, a monthly model with a set amount of team capacity works better.

You do not need a technical document at the start. Telling us what you want to do, and your budget range if you have one, is enough for us to talk about the rough size of the project.