Skip to content
LokumTech.

Custom modules

The feature you need, built as a module the next upgrade cannot delete.

Editing a core Blade file works, right up until the release that overwrites it. We build on the documented extension points — observers, view composers, jobs, permissions — and deliver a private module in your own repository, with the Turkish and English strings in place from the first commit.

Book a discovery callHow we price it

Two ways this usually starts

Either somebody already customised it, or the thing you need was never there.

Both are common. The second is more common in Turkey than anywhere else, because the gaps are Turkey-shaped and nobody has filled them.

What people try first

  • We copied the invoice create template and edited it. The update overwrote it.
  • We changed the login page. It came back after the version upgrade.
  • Someone added a column straight to the database and now nothing writes to it.
  • We tried to override a component from a module and it did not take effect.
  • We built it on the cloud version and it does not save. On-premise it did.
  • There is a field on the customer profile that only exists in our heads.

What is actually missing

  • Çek ve senet takibi. There is no app for it, in any category.
  • A real cari ekstre per customer, not just a closing total.
  • Tevkifat on the invoice, with the codes the e-invoice document needs.
  • Adding items to an invoice by scanning a barcode.
  • Taksit tracking on a receivable, with what is due when.
  • The one report finance actually asked for, which no report app produces.

The extension points

Five mechanisms. Everything we build uses these and nothing else.

This is not a philosophy, it is the documented API surface. Anything built outside it is a file waiting to be overwritten, and the overwrite always arrives on a day you needed the system.

Observers

Eloquent observers registered in the module's own service provider, with a class extending Akaunting's observer abstract. This is where "when an invoice is created, also do this" belongs. It survives upgrades because it is your file, attached through a documented hook, rather than a change to theirs.

View composers

The answer to every "how do I change the invoice screen without losing it" question in the forum. A composer can replace a section, swap a whole template, or push scripts onto an existing stack. Core Blade files stay exactly as shipped, which is the only reason the next update is boring instead of memorable.

Jobs

Akaunting creates, updates and deletes records through jobs rather than in controller bodies, so the same logic is reachable from the REST API and from the console. We follow that, which means the feature you paid for also works in an import, a scheduled task and an integration — not only on the screen it was drawn for.

Laratrust permissions

Registered in the module's installation listener and then checked as a permission rather than by role name, because your users will create custom roles and the documentation says so explicitly. Skip this step and the menu item appears and then returns 403, which is one of the most common "the module is broken" reports there is.

Menus, search, reports

Sidebar entries by listening for the admin and portal menu events, separately, because the client portal is a different surface. List filtering by shipping a search-string configuration that core merges in and then handles for you. Settings, reports and widgets declared in the module manifest. Declarative, and all of it in your repository.

How a module gets built

A paid discovery, then fixed phases, then a repository you own.

The discovery is a deliverable, not a sales stage. If you read the spec and decide not to build it, you keep the spec — and you have spent the cheapest money available to find that out.

  1. 01

    Discovery and a written spec

    Paid, timeboxed

    We sit with the people who will use it, read your install, and write down what the module does, what it explicitly does not do, and what finished means. Acceptance criteria, not adjectives.

  2. 02

    Scaffold and the first slice

    Week 1

    The module skeleton, the migrations, the model, and one working path you can click end to end. The argument about the shape of the thing happens here, while changing it is still cheap.

  3. 03

    Build on the extension points

    2–8 weeks by size

    Observers, composers, jobs, permissions. Migrations designed to be added to across releases rather than rewritten each time. REST endpoints where you need another system to read or write.

  4. 04

    Turkish and English from the start

    Not a later phase

    Both language files together, because retrofitting strings costs more than writing them. If the module renders a PDF, that includes embedding a font with the Turkish characters in it — DomPDF does not do that by default, and broken non-Latin output is a long-standing class of bug rather than a one-off.

  5. 05

    Delivery into your repository

    Before the invoice closes

    The module in your own git repository, with install and upgrade instructions, a version history, and a written note of which core version it was verified against. No marketplace approval, no revenue share, nothing to renew with us to keep using it.

What is in the handover

  • The module source, in your repository, under your account
  • A manifest declaring the aliases, providers, settings, reports and widgets
  • Migrations written for incremental releases, not one file that can never be changed
  • Turkish and English language files, complete, not partial
  • Install and upgrade instructions written for your admin, not for us
  • The core version it was verified against, in writing
  • A list of every core behaviour it depends on — which is the list to re-check after an upgrade
  • REST endpoints and their permissions, where the module has them
We reply within one business day. Turkish and English.

Scope and honesty

What we will build, what we will refuse, and the ongoing cost nobody mentions.

Akaunting's version-compatibility policy states that module authors do not have to keep modules backward compatible, because users receive the module version that shipped with their core version. That is reasonable for Akaunting, and it means one specific thing for you: an unmaintained custom module has a date on it. We say that before you buy one, and we quote the compatibility retainer alongside the build rather than after the first upgrade breaks something.

We will build

  • A private module in your repository, on documented extension points only
  • New entities with CRUD, plus the reports and widgets that make them useful
  • Turkey-specific logic: tevkifat, cari ekstre, çek and senet tracking, TDHP-aware reporting
  • Integrations as modules: Turkish payment gateways on the payment library already in the stack, Turkish e-commerce and marketplace sync, MT940 or OFX bank statement import
  • Document and invoice PDF output, with fonts embedded so Turkish characters actually render
  • REST endpoints for your own systems to call, with their permissions registered properly

We will refuse

  • Editing core files or core Blade templates. If that is genuinely the only route, we will tell you the feature is not safely buildable rather than build it anyway.
  • Custom modules for Akaunting Cloud. Custom code is effectively an on-premise capability, and pretending otherwise spends your money on something that will not save.
  • Removing Akaunting's branding. The licence forbids it, and the White Label app is the legitimate route.
  • A module with no maintenance line, where it hooks core behaviour that moves between releases. We will quote it and say plainly what happens if you decline.
  • App Store submission bundled into a client build. It is a separate engagement, with a review process and a timeline we do not control.

How it is priced

Discovery, then phases, and a retainer we quote whether or not you want it.

Two entities and a report is a different animal from something that hooks invoices, prints documents and exposes an API. The phases say which one you actually have, before anybody commits to a number for the whole thing.

Discovery

Quoted after assessment

Timeboxed and paid. The output is a written spec with acceptance criteria and a fixed price for the build. Yours to keep, and yours to take to somebody else.

  • 1–2 weeks
  • A spec, not a proposal
  • Credited into the build

Fixed-price phases

Quoted after assessment

The build, in phases with their own acceptance criteria, so you are never holding a half-finished thing you cannot evaluate.

  • Small — one entity, CRUD, a report: 2–3 weeks
  • Medium — cross-cutting logic and custom PDF output: 4–8 weeks
  • Larger work scoped in phases after discovery

Compatibility retainer

Quoted after assessment

Per release: your module re-verified against the new core, and fixed where the core moved under it. Optional, and the honest reason it exists is written above.

  • Re-verified each core release
  • Included in the maintenance retainer
  • Priced per module, not per hour
Invoicing entity: Lokum Tech LLC
The repository and the copyright are yours
Day rate available where the scope is genuinely open-ended
Written scope before any work begins

Starting prices for these packages are being finalised. Ask on a call and we will give you a number, not a range.

Straight answers

Questions before commissioning a module.

Why not just edit the file? It works today.
It does, and it will keep working until the release that replaces that file. Then somebody has to remember what was changed, find it in a diff, and redo it under time pressure. The forum has years of threads from people in exactly that position, usually about the invoice screen or the login page. A module costs more once and nothing afterwards; an edited core file costs a little every upgrade, forever, and occasionally costs a day.
Who owns the module?
You do, from the first commit. It lives in a private repository in your account, the copyright is yours, and there is no revenue share, no marketplace listing and no licence fee to us. If we stop working together you keep a working module, the instructions to install it, and the note saying which core version it was verified against.
Could it go in the Akaunting App Store instead?
Possibly, but it is a separate engagement and usually the wrong first move. Marketplace distribution needs an approved developer account and a review process whose timeline is not ours, and it changes the design brief: an App Store module has to work for everyone, which costs more than one that has to work for you. Our default for client work is a private module. App Store publication is a deliberate product decision, taken on its own.
Will it survive the next upgrade?
That is exactly why we only use documented extension points — observers, composers, jobs, permissions — rather than touching core. But the honest answer has a caveat: Akaunting's version-compatibility policy explicitly frees it from keeping your module working, so a module that hooks core behaviour needs re-verifying each release. We hand you the list of behaviours it depends on, and we quote the retainer that checks them. Declining the retainer is a reasonable choice; not knowing about it is not.
Can you build this for our Akaunting Cloud account?
No. Custom modules are effectively an on-premise capability — there are reports of custom fields saving on-premise and silently not saving on cloud, and there is no route to deploy your own module into a hosted tenant. If custom code is what you need, that is a straightforward argument for self-hosting, and it is one of the more honest reasons to move.
We need a report, not a feature. Is that a module?
Sometimes, and sometimes you should buy an app instead. A customer statement, for example, is a paid report app in the App Store — if that is what you need, we will tell you to spend the app price rather than commission us, and we would rather lose that sale than take it. Where the report genuinely does not exist, a module that declares a report is a small, cheap, well-bounded piece of work.

Every good build starts with a conversation.

Tell us the process that hurts. We will tell you honestly whether we are the right studio for it — and if we are not, who is.

Book a 30-minute callWho does the work