Skip to content
GlabIT
GlabIT

Portals · internal platforms · integration · modernisation

Secure custom web applications

Custom web application development in Romania for business portals, internal platforms, e-commerce systems and APIs, specified and security-reviewed to scope.

Book an assessment

In one sentence

GlabIT designs and builds business-critical portals, internal platforms, e-commerce systems and APIs around your workflows — with a written specification, documented architecture, explicit acceptance criteria and security controls agreed before anything is released.

Who it is for

  • Organisations running critical work on fragile spreadsheets, e-mail threads and disconnected tools, where errors and re-keying now carry a real business cost
  • Companies whose customers, partners or suppliers expect a portal — accounts, documents, orders, invoices, tickets — with access control designed for the data it protects
  • Operations and finance teams that need an internal platform for approvals, planning and reporting, integrated with the accounting, ERP and payment systems already in place
  • Owners of an ageing application on unsupported technology who need it modernised, or a selected e-commerce or SaaS build where the scope is well defined

Software shaped by your workflows

A custom application is justified when the way you work is specific to you and the tools you have stopped fitting it: quoting that lives in a spreadsheet only one person understands, orders re-keyed between systems, a partner process held together by e-mail. GlabIT has built software since 2008 — portals, order and booking systems, e-commerce back offices, internal dashboards and the APIs that connect them to accounting, ERP and payment systems — for clients in Italy, Romania and other markets.

What a serious buyer needs from that history is not a technology list. It is the discipline around the build: a specification before a commitment, documented architecture, explicit acceptance criteria, iterations you can inspect, and security requirements agreed in scope rather than assumed.

What we build

  • Customer, partner and supplier portals. Accounts, roles, documents, orders, invoices, tickets and notifications, with an access model designed for the data each party may see.
  • Internal operational platforms. Approvals, planning, reporting and administration areas that replace the spreadsheets and manual hand-offs your teams have outgrown.
  • API and system integration. Documented REST APIs of your own, and reliable connections to the accounting, ERP, CRM, payment, identity and messaging systems you already run.
  • Product modernisation. An existing application moved off unsupported technology onto a maintainable architecture — after a written review of what is worth keeping.
  • Selected e-commerce and SaaS work. Shops, booking flows and first product versions where the scope is well defined — including platform-based builds where a platform genuinely fits better than custom code.

How the engagement runs

Specify before you commit

Workshops with the people who will use the application — not only the people commissioning it. The output is a functional specification with explicit acceptance criteria, estimated in writing. Both the price and the acceptance test come from that document, so “done” is never a matter of opinion.

Architecture you can read

Interface design, data model, integration map and threat model are agreed before production code is written. The architecture and data flows are documented deliberately, so that operating and extending the application never depends on the memory of the people who built it.

Iterations you can inspect

Development proceeds in increments on a staging environment you have access to. The proposal and release plan identify the checks included in each release — automated tests within the agreed coverage, code review, and the security checks defined in scope. You see working software early and steer while steering is cheap.

Handover that holds up

Go-live with a repeatable deployment process, environment documentation and a handover your team can act on. Hosting, monitoring, updates and support are available under separately contracted plans — with the service levels stated in the plan, not implied by a web page.

Security from a security-capable team

GlabIT is also a security firm: the engineers who deliver penetration tests and AI security assessments work alongside the build teams. For application projects that means security requirements are part of the specification, and — where the scope includes it — the finished application is tested by a reviewer genuinely separate from the team that built it. Security work reduces risk; no supplier can make software vulnerability-free, and we put that limitation in writing rather than behind it.

Deliverables

What you receive

  • Discovery output

    A written summary of the workshops — the process as it actually runs, the users and roles, the data, the integrations and the constraints — so scope decisions are made on facts, before any commitment.

  • Functional specification and acceptance criteria

    What the application must do, agreed in writing and estimated before development starts, with explicit acceptance criteria — the same document both sides use to judge whether it is done.

  • Architecture, data model and integration map

    The application architecture, database design and a documented map of every system it connects to, written so any competent team could operate and extend the application after handover.

  • Source code and automated-test scope

    Version-controlled source delivered in a repository under the ownership and licence terms of your contract, with the automated-test coverage defined in the proposal — what is tested, how, and what the release plan checks before each release.

  • Security and data-protection design

    The security requirements agreed in scope — authentication and access model, input handling, logging, data-protection measures for the personal data involved — documented as part of the design, not asserted afterwards.

  • Deployment and operational handover

    A repeatable deployment process, environment documentation and handover to your team; hosting, support and penetration testing are available as separately contracted options with their own written terms.

Engagement model

How it runs

Model
Fixed price for a specified scope, delivered in iterations reviewed on a staging environment; time-and-materials where the product is still evolving; hosting, support and maintenance under separate written plans.
Typical timeline
Set in the proposal for the agreed scope; larger builds are phased so a first usable version is in your hands early.
  1. 01

    Discover and specify

    Workshops with the people who will actually use the application. We map the process, data and integrations, then write the specification and acceptance criteria and estimate against them.

  2. 02

    Design the architecture

    Interface design, data model, integration map and the security and data-protection requirements for the data involved — agreed before production code is written.

  3. 03

    Build in reviewed iterations

    Development in increments you review on a staging environment. The proposal and release plan identify the checks each release goes through — automated tests, code review and the security checks agreed in scope.

  4. 04

    Release and hand over

    Go-live with a documented deployment process and operational handover. Where contracted, we operate the application under a written plan; otherwise your team takes over with the documentation to do it.

FAQ

Questions a sceptical CISO asks

Which technologies do you use?

Those the requirements call for, chosen for maintainability and support life rather than fashion — typically object-oriented PHP with Laravel on the server, Vue or other modern JavaScript for interfaces, Astro for content-heavy fronts, MariaDB or PostgreSQL, Redis, documented REST APIs, and established e-commerce platforms such as PrestaShop, Magento or WooCommerce where a platform is the better answer. The proposal explains and justifies the choice.

Who owns the code, and how dependent on you do we stay?

You receive the agreed source code, documentation and data exports under the ownership and licence terms of your contract. Pre-existing GlabIT material, open-source components and third-party platforms remain subject to their applicable licences, which the contract lists. The delivery is designed to reduce avoidable supplier dependency — documented architecture, a handover your team can act on — not to guarantee the absence of all platform lock-in, which no supplier can honestly promise.

Can you take over an application someone else built?

Usually, yes. We start with a review of the code, dependencies and security posture so you know the state of what you have, then either stabilise and extend it or propose a rebuild where that costs less than maintaining it — with the reasoning in writing.

What does "secure" actually mean here?

Security requirements are agreed in scope and designed in — threat modelling, authentication and access control, input validation, hardened configuration, TLS, logging you can investigate with. The proposal and release plan identify the checks included in each release. Penetration testing is included when contracted, performed by a reviewer separate from the build team. Security work reduces risk; it does not make software vulnerability-free, and we say so in the report.

Is the interface accessible?

Accessibility requirements and the target standard are agreed in scope, together with how conformance will be validated. We do not claim WCAG conformance unless a target level and a validation method are contracted — an unverified claim would be worthless to you.

Do you host and support the application afterwards?

Where contracted, yes — hosting, monitoring, updates, backups and a defined way to request changes, under a written plan whose service levels are stated in the plan itself. Nothing on this page implies uptime, recovery objectives, response times or backup commitments outside a signed plan. We can also apply the same practices to infrastructure you already operate.

Discuss your application

Describe the process the software must carry and who will use it. We come back with a written view of scope and, wherever the scope can be pinned down, a fixed price against explicit acceptance criteria.

Discuss your application

Often combined with

Secure engineering

Web and application development with security built in: secure SDLC, code review, hardened hosting.

Read more

AI product engineering

AI use cases validated, prototyped and engineered for production — evaluation on real cases, documented data flows, human oversight and security controls.

Read more

Penetration testing

Web, network, cloud and mobile testing to OWASP WSTG and PTES, with retest included.

Read more