Engineering / selected projects

Test the part that could change the decision.

Custom software gets expensive when you have to fund the entire project before anyone knows whether its most uncertain part works.

When we can isolate that uncertainty, we prefer to start there. It might be an integration, an AI agent for a specific task, a critical rule, a flow using test data, an inspection of an existing system or a document sample processed end to end.

  • A preview before deciding
  • Clear scope before delivery
  • Continuity without hidden dependencies

What kinds of problems come here?

  • “We keep copying information between systems.”

    Simple automation may solve it. The APIs may not allow it. An existing SaaS may already do it better and more cheaply.

    Before building a platform, we try to find out which answer is true.

    When the uncertainty is technical, we can run the flow with test data and show where it breaks.

  • “We already have a system, but need to extend or fix a part.”

    Existing software does not always need rebuilding.

    We can start by understanding what exists and testing the risk blocking the next decision: integration, authorization, ingestion, operating cost or another specific part.

    Sometimes the conclusion is to keep things as they are, refactor a part or replace a tool. That is also a useful result.

  • “We built an AI prototype. Now it needs to become real software.”

    A working interface alone does not tell you whether a system is ready for production.

    Before making a broad promise about production readiness, we examine the code, data, integrations and risks that matter for the intended use.

    The first job may be finding out what is worth keeping.

  • “We have too many documents and too much manual work.”

    For search, field extraction, review or moving information from documents into another system, we start with one document type and a clear task.

    The output needs to be checkable against the source. Errors need to be visible.

    The economics only work if review does not consume all the time the automation was meant to save.

Sometimes the best project is to build nothing

  • First, we compare the problem with reasonable alternatives

    An existing tool may already solve it.

    It may be too early.

    Continuing manually may be cheaper for now.

    Configuring what you already use may be enough.

    Luminiware gains nothing by turning every assessment into a system you will regret maintaining.

When understanding the problem is work in itself

  • An assessment can be a paid stage on its own

    Some projects are simple enough to assess quickly.

    Others require examining code, mapping dependencies, understanding data and reconstructing undocumented decisions.

    In that case, you receive findings, relevant risks, possible approaches and a recommendation for next steps.

    That material should remain useful even if you choose someone else to implement it.

When a pilot makes sense

  • A concrete technical question

    A pilot makes sense when a concrete technical question can be answered without building the whole system.

    For example: does this integration work under our conditions? Can this flow run end to end? Can this document be processed with an acceptable review effort? Is this prototype worth keeping or would restarting be cheaper? What does operating this part actually cost?

    We agree in advance on what to test and what would count as a useful result.

    A pilot can conclude that something is not worthwhile. That is better than discovering it after months of implementation.

If the pilot makes sense, the project continues in stages

  • The larger implementation comes later

    The larger implementation comes later, with its own scope.

    We agree on milestones, acceptance criteria, responsibility for data and infrastructure, and what happens after delivery.

    Commissioning one stage does not require you to commission the next.

What stays with you

  • Agreed code, documentation and access

    For paid work, we agree on the assets included: code, documentation, operating instructions, access and relevant accounts.

    We also make recurring costs and third-party dependencies clear.

    Any maintenance is an explicit engagement.

    Leaving should not come with surprises discovered at the end.

The experience behind Luminiware

  • DefendaMe

    Vinícius Menezes is CTO and cofounder of DefendaMe. He works on the product’s architecture and evolution, including ingestion, search, data processing, observability and integrations.

    The case distinguishes his individual contributions from work commissioned from Luminiware and records the limits of the available evidence.

Start with the problem.

Tell us what happens today and what needs to change. The first answer does not have to be a new system.