Web-based business software shaped around how your company really works, where packaged tools fall short.
Every company has at least one process held together by spreadsheets, e-mail threads and programs that never talk to each other. Custom software development means moving that process into a single system that follows your rules. As a software company based in Istanbul, we design, build and run enterprise software for work such as quoting, orders, stock, field operations, approvals and progress billing.
For us, a software project never starts with code. It starts with listening to how the work gets done today. Once it is clear who enters which data, who approves what and which report has to be on the desk on Monday morning, we draw the screens. The result runs in the browser, talks to your accounting and ERP software, and belongs to you, source code included.
- 01SMEs that want to move their operations off spreadsheets and e-mail into one system.
- 02Companies with a workflow of their own that no packaged ERP or CRM handles properly.
- 03Organisations with an ageing in-house system that has become hard to maintain.
- 04Brands that want to work with dealers, branches or suppliers through a shared web portal.
- 05Managers who need to see who did what, and when, across approvals, progress billing or orders.
- 06Businesses that want a solid first system before hiring an in-house software team.
What is custom software, and how is it different from an off-the-shelf package?
Packaged software is built for the average needs of an average company. For areas that work the same everywhere, such as accounting, payroll or e-mail, that is the right choice and we won’t suggest rewriting them. The trouble starts with the processes that set a company apart: a particular pricing logic, a multi-stage approval chain, progress billing calculated from field measurements, or stock visibility tailored to each dealer. At that point a package either falls short or forces the team to work its way.
Custom software models those processes as they are. Screens use your terminology, permissions follow your org chart, and reports answer the questions management actually asks. Because it is web-based, there is nothing to install: people reach the same system from the office, the field or home through a browser. Done well, it doesn’t compete with your packages but complements them. Your accounting program keeps the books; the custom system runs the work that feeds into them.
How does an enterprise software project work, and what is it built on?
Every project has a data model at its core. Screens built before customers, orders, products, projects, documents and the relationships between them are modelled properly will fall apart at the first change request. So in discovery we start by mapping entities and rules, then define roles: who sees, who edits, who approves and who only gets reports. We keep an audit trail for every critical action, so you can always find out who changed a figure and when.
On the technical side we build the interface with Next.js, React and TypeScript, business rules in Node or Python, and data in PostgreSQL. For hosting we recommend managed platforms such as Cloudflare or Vercel; where data residency or company policy requires it, we can deploy on your own servers instead. Connecting at API or database level to software such as Logo, Mikro, Netsis, Nebim, SAP Business One or Paraşüt is a natural part of scope in most projects.
Timeline and project flow: when can people start using it?
Trying to deliver a large system in one go is the riskiest path in custom software. Instead, we pick the single process that costs the company the most time and build the first release around it. Once real users have it, it becomes clear what works and what is missing, and the next modules are shaped by that learning. A well-bounded first release is usually in use within a few months; we share the exact timeline in writing at the end of discovery.
What we need from you during the project is not technical knowledge but a decision-maker and a short weekly review. At the end of each cycle you see a working build in the test environment, and anything you accept goes live. We plan migration from the old system as its own piece of work: data is first moved into a trial environment, the numbers are checked together, and only then do teams switch over. Nobody is left stuck between two systems.
Common mistakes, and how to recognise a good software project
The most common mistake we see is turning today’s mess straight into software. Putting a manual task on a screen doesn’t improve it; the process has to be simplified first. The second is involving users too late: a system management signed off on but the field team never adopted will be back in Excel within months. The third is leaving source code, servers and domains in the vendor’s accounts, which ties the company to a single supplier.
The signs of a good project are concrete. The team uses the new system without being chased, no data is entered twice, management gets the reports it wants without asking anyone, and a change request goes live in days rather than weeks. The code is readable and documented, and infrastructure accounts are in your name. If you hire your own developers tomorrow, they have everything they need to take the system over.
- 01Business analysis and process map
- 02Role, permission and approval model
- 03Web-based application and admin screens
- 04ERP and accounting connections
- 05Data migration from legacy systems
- 06Technical documentation and user training
We read the business first
We bring more than twenty years in media, sales and P&L leadership. Before turning a process into software, we want to know what it costs, whose time it eats and which decision it feeds.
We know how to run what we build
We build and run our own products: Rocketly CRM, ad10, Kaynak and Tercih Robotu. Backups, permissions, release management and zero-downtime updates are part of our daily work, not theory.
It talks to what you already use
A new system doesn’t have to replace your accounting or ERP software. We design data exchange with tools such as Logo, Mikro, Nebim or e-Fatura from the start, so nothing is keyed in twice.
Code, data and accounts are yours
Source code lives in your repository, and servers and domains are held in your name. On handover we leave documentation covering architecture, setup and business rules, so your freedom to carry on independently is secured from day one.
Discovery and process map
We talk to the people doing the work, go through existing spreadsheets and forms, and write down today’s flow step by step, including where it gets stuck.
Prototype and scope
We walk through the flow together on clickable screens, then agree in a written scope document on what goes into the first release and what waits.
Build and acceptance testing
We work in two-week cycles, open a test environment you can try with real data at the end of each one, and move on only with your sign-off.
Rollout, training and support
We migrate the data, train teams by role, stay close during the first weeks and then continue with maintenance and further development on a regular rhythm.
What drives the cost of custom software is the complexity of the business rules, not the number of screens. In a discovery call we cover the processes in scope, user roles, approval steps, the ERP and accounting systems to connect, the state of legacy data, hosting preferences and the support you expect after launch. We then prepare a written proposal with first-release scope, deliverables and timeline, and we list what is out of scope in the same document, so no surprise costs appear mid-project.
Let’s talk about this
It depends on how many processes are in scope, the integrations involved and the state of your existing data. A first release built around one critical process is usually in use within a few months, with further modules added on top. At the end of discovery we share a written, week-by-week plan and show you a working build every two weeks.
For areas that work the same in every company, a package is the sensible choice. For processes that set you apart, that force your team to work around a package, or that get lost between several programs, custom software pays for itself quickly. We weigh both options openly in discovery and won’t recommend building if you don’t need to.
Price is shaped by the complexity of the business rules, user roles and approval steps, the systems to connect, the volume and cleanliness of data to migrate, hosting preferences and the support you expect after launch. After a discovery call we send a written proposal covering scope, deliverables and what is explicitly excluded.
Yes, and it is a routine part of most projects. We can exchange data with software such as Logo, Mikro, Netsis, Nebim, SAP Business One or Paraşüt through APIs, direct database access or file transfers. We agree up front which system is the source of truth for each piece of data, so nothing is entered twice.
Both are possible. We recommend managed cloud hosting for most projects because it simplifies maintenance and security updates. If company policy, data residency or your data protection assessment calls for your own servers, we deploy there and plan the update process accordingly.
We migrate it. First we review the data and clean out duplicate, incomplete or conflicting records. Then we run the transfer in a trial environment and check totals and sample records with you. Teams switch over only once the numbers match, and the old data stays available as an archive.
You do. Source code lives in your repository, and server, database and domain accounts are opened in your company’s name. On handover we leave documentation on architecture, setup and business rules. You can continue with your own team or another software company whenever you choose.
You don’t need technical knowledge, just someone who knows the business and can make decisions. In short weekly meetings we show progress and put decisions to you in plain language. Every cycle ends with a working build you can try in a test environment, and you decide what goes live.
Yes. We offer a monthly arrangement covering security updates, backup checks, performance monitoring, bug fixes and new development as needs change. Business rules evolve and the software has to evolve with them; regular maintenance largely removes the need for a full rewrite a few years down the line.
I usually reply within 24 hours.