From first message
to finished software.

Dervens Philemond leads PhreeLabs, with work spanning creative applications, custom engines, and tools for specific workflows.

Dervens directs the work from the first idea to the final test. You work with one accountable person from first message to handoff.

The whole project runs in writing, by email or written messages: no calls or meetings are needed, and every decision stays on record.

1. 01

   Inquiry

   Send the form or an email: what the software should do, who will use it, and what’s broken or missing today.

   You get a personal reply within 2 business days.

2. 02

   Discovery

   Map the people, inputs, rules, and results. What should the software make possible, and what must it get right?

   A free written project discussion by email, with no obligation to continue.

3. 03

   Scoped Plan

   Agree on the essential functions, technical constraints, and how the result will be checked. The first build stays focused enough to evaluate.

   A fixed quote for a clearly scoped first phase, agreed before any work starts. Nothing is billed beyond it without your written approval.

4. 04

   Build and Review

   The software is built against the scoped plan and reviewed as it takes shape.

   A short written update every week, with a version you can try whenever there’s something new to see.

   Ask for changes in writing at any time. Each one gets an estimate first and starts only after you approve it, so the price never moves without your say.

5. 05

   Verification

   Try the software on the task it was built for, using the acceptance examples in the plan. Review working behavior, relevant failures, and operating conditions. The in-house product pages show documented engineering checks and their conditions.

6. 06

   Handoff

   The finished software is handed over with what was agreed in the scoped plan.

   You receive the source code, setup and build instructions, documentation, and the support agreed in the plan.

   Custom code written for your project is yours once the final invoice is paid. If the project reuses PhreeLabs’ existing tools, you get a permanent license to use them in your software.

The scoped plan turns a broad request into a decision you can make in writing. It should make the relationship between the work, price, and intended benefit clear.

• Purpose: the people, task, current constraint, and improvement being sought.
• First release: the input, essential behavior, usable output, and explicit exclusions.
• Dependencies: required access, supplied content, third-party services, costs, and decisions that affect delivery.
• Acceptance: representative examples, relevant failure cases, supported environments, and the evidence to review.
• Changes: a written decision on added work and its effect on scope, price, and timing.

There is no need to arrive with a technical specification. Your description of the work is the starting material.

The handoff is defined in the scoped plan. Depending on the project, the useful package includes:

The Version

The delivered source and build, with a clear record of what changed, the supported workflow, and its operating requirements.

The Evidence

Acceptance checks and their conditions, with unresolved issues distinguished from completed work.

The Instructions

Setup, build, and day-to-day use; required accounts or services; data and export arrangements where applicable.

The Continuation

Third-party components and licenses, agreed support, and a clear distinction between fixes and later feature work.

This makes the result easier to operate, evaluate, and continue developing after handoff.

Each language is picked for the job it does. The in-house products show where each one earns its place.

Swift and AppKit

Native Mac interfaces. Explainer Studio’s canvas, timeline, and export run on Apple’s frameworks with no web view.

HTML, CSS, JavaScript

Polished interfaces, animation, and interactions. Architect’s workspaces are React inside a native Mac shell; this website is plain HTML, CSS, and JavaScript with no framework (see Website Design & Development).

Python

Backend workflows, automation, and integrations. Architect’s document saving, validation, and export; Webs’ asset generation and validation tools.

C++

Demanding computation, simulation, or engine code where performance matters. Webs’ 60 Hz simulation, collision, and combat, and the preview inside Architect, which runs the same match code.

Lua

Rules that change without recompiling. Webs’ game rules, reloaded live and checked in a sandbox.

How a Web Interface Connects to Python and C++

Testing and Performance

• Explainer Studio compares exported frames against preview renders: 50.96–54.80 dB PSNR at 14 frames.
• Webs measured input response before and after a renderer change: median 13.89 ms, with no one-second stalls in 597 frames.
• Architect’s map codec runs 248 strict checks, repeated under AddressSanitizer and UndefinedBehaviorSanitizer.

Interoperability

• Explainer Studio: one command set shared by the app, a command line, and an MCP server.
• Webs and Architect: one .wbs document format with revision conflicts, and one Lua contract shared by the editor and the engine.

Everything shown on this site is PhreeLabs’ own work, not client commissions.

Custom code written for your project is yours once the final invoice is paid. If the project reuses PhreeLabs’ existing tools, you get a permanent license to use them in your software.

Third-party libraries are listed with their licenses at handoff, so you know exactly what your software depends on.