2Wee

Why 2Wee

Most internal tools get built twice. Once in Laravel — the models, the logic, the validation. Then again in the frontend — the forms, the components, the build pipeline. Two layers to maintain, two places for things to drift apart.

2Wee removes the second layer entirely.

You describe your screens in PHP. A customer card, a sales order, a payment journal. The client renders them as a fast, keyboard-driven terminal interface. Your users never touch a mouse. Experienced operators move through records at the speed of muscle memory — faster than any web form.

It is the right tool for the people who live in your software all day.

Try the demo

A live demo is running at demo.2wee.dev — a sample ERP application with customers, sales orders, and purchase documents. No login required.

Prefer the native client? Install it, then connect directly to the demo server from your terminal:

2wee https://demo.2wee.dev/terminal

The demo server is located in New York. If you are connecting from far away you may notice some latency — this is expected. The web terminal renders the TUI on the server and streams it to your browser. The native client has no such constraint — it runs locally and only the API calls travel over the network.

Heritage

In the 1980s, Navision built the fastest enterprise data entry system the world had ever seen. It ran in a terminal, was keyboard-only, and was so fast that experienced users could process invoices faster than the system could print them. The pattern was brilliant: the server owns all logic, the client just renders. No state, no sync, no drift.

2Wee picks up where that era left off — not as a clone, but as an evolution using modern technology. The same philosophy, the same speed, the same respect for the keyboard as the fastest input device ever made.

2Wee also inherits the Navision architectural pattern: the Page (your Resource) handles presentation, the Codeunit (your Action class) handles business logic. They are separate concerns. Your save action for a sales document doesn't just update a field — it handles everything that happens when a document is saved. One class. One operation. The same pattern that made Navision maintainable for decades.

How it works

Your Laravel app returns JSON screen descriptions. The 2Wee client renders them as a rich terminal interface. The user interacts with keyboard only.

User ──keyboard──> 2Wee Client ──HTTPS──> Your Laravel App ──database──> Data
                      │                         │
                      │<── ScreenContract (JSON) ┘
                      │
                      v
                   Terminal

The client contains zero business logic. It does not know what a customer is, what an invoice looks like, or how to calculate a balance. It renders what your server sends. This is the single most important design principle.

What you can build

• Cards — single-record forms with sections, fields, and drill-downs
• Lists — scrollable tables with type-to-search filtering
• Documents — headers with editable line item grids (Sales Orders, Purchase Orders)
• Journals — full-screen editable grids with totals and posting
• Lookups — relational field selection with autofill
• Actions — send email, print, export, post — any custom operation
• Menus — nested navigation with tabs

All driven by your server. All keyboard-only. All fast.

The protocol

2Wee is protocol-first. The JSON contract between client and server is open, documented, and framework-agnostic — a deliberate architectural decision, not an afterthought.

Laravel is the official server implementation, but any backend that returns JSON over HTTPS can drive the client. Rails, Django, Express, Go — if it speaks the protocol, it works. Teams not on Laravel get the same terminal interface, the same speed, the same keyboard-driven experience. The client does not know or care what generated the JSON.

Start here

I want to...	Start with
Build an app with Laravel	2Wee for Laravel
Understand the client	2Wee Client
Build a server in another framework	The Protocol