You may not need this
Custom development is expensive and not every company needs it. If your site shows information, collects forms and carries a blog, an off-the-shelf content management system will do the job. Saying that doesn't help our sales, but correcting the wrong investment later costs more.
Here's the dividing line: does the site have rules, or only content? If there's no price, permission or calculation that changes from one user to the next, you can stop reading here.
How is this different from design?
On a brochure site, changing a page means changing the text. Here, changing one rule affects every screen, permission and report tied to that rule.
So half the work isn't coding, it's getting the rules written down correctly. That's also why we don't quote before a scope document exists.
What do you build it with?
We choose against three questions: will it still be supported in years to come, can you find a developer to take over, and can search engines read the content without running JavaScript?
What we don't use belongs on the list too: Flash, FrontPage, Fireworks and classic ASP appear in none of our current projects. If your site was built with those, the work isn't an update, it's a rewrite.
What kind of work do you take on?
- Dealer and service portals: pricing by role, order entry, account tracking
- Product catalogue and technical document management, variant and dimension tables
- Quote workflows: from a form to a PDF quote, with approval and revision tracking
- Booking and appointment systems, with capacity and reminders
- Internal admin panels: requests, tasks, documents, permissions
- Integrations: ERP, bookkeeping, shipping, e-invoicing, virtual POS, marketplaces
- Takeovers: code review, documentation, staged renewal
How does an integration get built?
An integration means two systems talking to each other so the same data doesn't get typed in twice. This is where projects stall most often: the other side's documentation is incomplete, field names don't line up, and nothing says what happens when something fails.
So we split the job in three. A field mapping table: which field corresponds to what. Failure cases: what happens if the connection drops or the data is rejected. And retry logic. We don't start writing code until all three are written down.
- ERP and bookkeeping: product, stock, account and price transfer
- E-invoicing and e-archive: issuing documents through an integrator
- Shipping: creating consignments, barcodes, matching tracking numbers
- Payment: virtual POS or a payment provider; card data never reaches us
- Marketplaces: product and stock synchronisation, pulling in orders
What do you do about security?
Security isn't a separate module, it's a habit applied at every step. These are our minimum rules:
- Everything arriving from a browser is validated again on the server; client-side checks are a convenience, nothing more
- Passwords are hashed with bcrypt and never stored as plain text anywhere
- Permissions are checked on the server; a hidden button is not a permission boundary
- Rate limiting, a honeypot and bot verification on login and form endpoints
- Parameterised database queries, type and size checks on file uploads
- Card data never lands on our server; it stays inside the payment provider's frame
- A data inventory, retention periods and a deletion procedure, as required by KVKK (Turkey's data protection law)
- Once backups are set up, a restore is actually attempted; an untested backup isn't a backup
Who ends up owning the software?
The system runs in your name: the domain is yours, the panel access is yours, the data inside it is yours. You can export your product, customer and order records whenever you like. You don't pay us an annual licence to keep the site switched on.
Transferring the source code is a separate conversation. The real cost of software isn't running it, it's designing, writing and documenting it, which is why code transfer isn't inside the package price. Clients who want it raise it in the meeting and we put the price and the scope in the contract. We say this up front so there's no surprise later.
Once code transfer is agreed, the handover file contains the Git repository, a database backup and the schema files, the list of environment variables, the third-party service accounts, an installation guide and a list of known gaps. We write that last item out deliberately. No software is handed over complete; the honest thing is to put the gaps on paper.