Service requests and project intake for MarrowGlass.
This repository is the public front door for working with MarrowGlass. Open an Issue to request a project, a review, or a consultation. Approved work is then moved into a private workspace, where it belongs.
MarrowGlass is a small web engineering studio. We build and maintain systems that have to stay online, stay correct, and stay inexpensive to run.
Our work is grounded in a few consistent choices:
- Reliable backend engineering. Boring, correct services that fail in predictable ways.
- Secure systems. Threat models written down, secrets kept out of code, boundaries respected.
- Efficient server usage. The smallest deployment that handles real traffic, not the largest one that looks impressive.
- Accessible, high-quality UX. Interfaces that work for the people who actually use them, not only the people who demo them.
- Maintainable products. Code and structure the next engineer can read. Flashy prototypes are not the goal.
We do not publish testimonials, client counts, certifications, or uptime figures on this page. If you need references, ask in a private channel after a request is qualified.
Content-focused websites, landing pages, documentation and company sites.
Typical stack:
- Astro
- TypeScript
- Tailwind CSS
- CDN / static deployment
Dashboards, internal systems, customer portals, SaaS and business apps.
Typical stack:
- AdonisJS
- Vue with Inertia
- PostgreSQL
- object storage where needed
Public APIs, mobile backends, multi-tenant systems and larger platforms.
Typical stack:
- AdonisJS API
- Nuxt
- PostgreSQL
- Redis and background workers only when justified
Architecture review, security review, server optimization and UX review of an existing system. No new code is required; the output is a written assessment and a prioritized set of recommendations.
If you already know what you need, open a structured project request. The form asks for scope, stage, users, traffic, server tier, budget and deadline so we can give you a useful first response instead of a follow-up question.
If the shape of the problem is not clear yet, start a consultation instead. Tell us what you are trying to achieve and what is in the way. A short conversation is cheaper than a wrong build.
For general questions that are not a request, the Discussions board is the right place. Keep those public and non-confidential.
- Request. You open an Issue with enough context for a first read.
- Review. We read it, check scope against capacity, and identify gaps.
- Clarification. Missing pieces are asked for in the Issue. Nothing private is requested here.
- Estimate. Once the scope is clear, we share an estimate.
- Private workspace. If you accept, work moves to a private repository or a private communication channel. Public Issues are closed or left as a record of the initial request.
- Delivery. Work is done, reviewed, and handed over with enough documentation to be maintained.
We select architecture based on actual traffic, real workload, and available server capacity — not on assumptions or fashion.
In practice that means:
- Start on the smallest tier that handles the load with comfortable headroom.
- Add Redis, queues, or background workers only when a measured workload justifies them.
- Avoid microservices, containers, and Kubernetes unless the system genuinely needs them. A single well-structured process is usually the right answer.
- Prefer static and edge deployment for content that does not need a server.
The intake form asks for your server tier on purpose. It shapes the architecture from the first estimate.
This repository is public. Everything you write in an Issue or Discussion is visible to everyone and indexed by search engines.
Never submit any of the following through a public Issue or Discussion:
- passwords, API keys, tokens, or any credentials
- private source code you do not have the right to publish
- database URLs or connection strings
- payment information
- sensitive personal data
- details of a vulnerability affecting a live system (see SECURITY.md)
If something must be private, say so in the Issue and wait for a private channel to be opened. Do not paste it here.
Once a request is accepted, the actual implementation is moved into a private repository or another private communication channel. The public Issue remains only as a record of the initial request and is kept free of confidential information. This keeps your code, your data, and your decisions out of public view.
To report a security issue, read SECURITY.md. To propose changes to these intake forms, read CONTRIBUTING.md.