How the Allcancode platform worked
Allcancode brought interface design, application logic, code generation, and delivery into one development environment. I built it around a recurring problem in customer projects: turning a specific product idea into working software without spending most of the effort rebuilding the same foundations.
This is a product archive of my work on the platform from 2017 to 2024. Allcancode is a completed company chapter. The screenshots from its surviving website show the later product; the December 2020 brochure and early recording document earlier stages. They are evidence of different versions, rather than a current service offering.
From a design to a working interface
A project started with the screens people would use. The platform could import a Figma design or let a developer construct the layout directly. The December 2020 brochure describes a deliberate handover step after import: adjust the layout, then identify functional components such as input fields within the designer's shapes. References to the Figma file allowed later design changes to be imported when its structure remained compatible. Brochure, p. 4
The visual editor kept the application's screens, component hierarchy, and styling controls together. Developers could change spacing, typography, and layout while previewing the result at different device sizes. A shared approach served web and mobile projects. Brochure, p. 5
The later visual layout editor. The selected component connects the screen hierarchy to the canvas and its properties. Source: Allcancode platform website. Open any screenshot for its full-size view.
Reusable components were central to this process. A complex interface could be divided into smaller pieces, developed independently, and assembled into a screen. Those pieces could then be shared between projects as an organization's own component library. The goal was to make repeated work reusable while leaving room for the parts that made each product distinctive. Brochure, p. 5
Giving the interface behavior
The next step was to connect what appeared on screen to what the application did. Allcancode extended Blockly to express application logic, including routing, data binding, reactive behavior, and API integration. Blocks represented operations and their relationships, making the flow available for inspection inside the same environment as the interface. Brochure, p. 6
The block editor in the later platform. Source: Allcancode platform website.
The 2020 documentation includes libraries for form validation and date handling, connections to REST APIs, and middleware backends that integrated with existing systems. Existing code could be incorporated alongside blocks. This mattered when a customer's requirements extended beyond the components and operations already supplied by the platform. Brochure, p. 6
Keeping code available to developers
Visual development and conventional programming were parts of the same workflow. Developers could use JavaScript where needed, and the later product generated React, React Native, and Next.js source into a Git repository. Customers retained access to the application code independently of Allcancode. Platform overview
The code view alongside the visual development environment. Source: Allcancode platform website.
The earlier brochure records a broader set of framework targets and deployment integrations for that edition. Its lasting architectural point is the separation between the authoring tool and the delivered application: generating maintainable source, packaging the result, and delivering it to the web or mobile devices were explicit stages of the process. Brochure, p. 7
Inspecting and improving the application
The later platform exposed execution steps and data context alongside the interface. Its published toolset also included templates and logic analysis. These controls brought investigation into the development workspace. Platform overview
Interface and execution context in one workspace. Source: Allcancode platform website.
Iteration was part of the product's foundation. The December 2020 brochure describes automatic version history for both interface layouts and code, with the ability to return to an earlier state. Together with reusable components, this supported a cycle of building, reviewing, changing, and delivering. Brochure, pp. 3 and 6
Applications built with the platform
I was involved in each of the following customer projects. They show how the shared development environment accommodated different users, integrations, and operating constraints.
Clio Muse Tours. A mobile-first audio-tour web application connected to the customer's existing backend. Offline use, a custom audio player, and mapping integrations let a visitor navigate the tour and its content together. Published case study
Swaplanet. An internal application joined clothing-processing and order-fulfilment workflows to Shopify and courier services. Its touch-oriented interface brought booking, sorting, photography, and fulfilment into an operational workspace. Published case study
The operational application's entry screen. Screenshot from Allcancode's published customer case study.
Arena of Life. A personal-development mobile app worked alongside a web application for professional coaches. The project connected individual progress tracking with the coaching side of the service. Published case study
From game authoring to application development
The platform grew out of the tools around Run Marco. Building a game maker raised a larger question: could the same approach help people construct other kinds of software? The transition toward an application maker began in 2017, as I describe in my original account of Allcancode's development.
My role connected that product direction to implementation: the common application framework, visual authoring, code generation, customer delivery, and the training that helped new developers use the platform. The customer work gave those decisions a practical test: an application had to fit the people and systems that would actually use it.
Sources and archive
- Allcancode platform overview — source of the later editor screenshots and published product description; reviewed 5 October 2026.
- December 2020 platform brochure (PDF) — the original eight-page document, including design import, layout, logic, version history, and delivery.
- Allcancode customer case studies — Clio Muse, Swaplanet, and Arena of Life descriptions and screenshots.
- My 2018 Allcancode history — first-person account of the transition from the game to the application platform.
- Early platform demonstration — preserved from my Allcancode archive; the original recording is named
SimpleProject.mov.