
[Cover Technologies](https://buildcover.com/) &mdash; or Cover &mdash; is one of the leading ADU manufacturers in Los Angeles, California. They’ve raised over $73MM to democratize the housing industry by producing affordable but luxurious homes at scale.

<ClientStats
    companyName="Cover"
    website="buildcover.com"
    funding={[
        { round: 'Seed', amountMmUsd: 1.6 },
        { round: 'Seed', amountMmUsd: 1.7 },
        { round: 'Series A', amountMmUsd: 10 },
        { round: 'Series B', amountMmUsd: 60 },
    ]}
    employeeCount={50}
    location={{ city: 'Los Angeles', state: 'California', country: 'USA' }}
/>

We began our partnership with Cover in January 2021 and have since developed a suite of software to support their manufacturing, procurement, and production teams in constructing ADUs more affordably, efficiently, and to a higher standard.

One project we hold in high regard is Cover Procurement, designed to avoid woes with the existing ERP. It didn’t entail replacing that ERP but rather supplementing it. Chief among our goals was to provide:

1. A simplified UI for interacting with the ERP
2. Responsive design for on-site workers, which the ERP lacked
3. Streamlined workflows for procurement, meaning a simple button press may replace several actions users would manually perform in the ERP.
4. Dead simple data entry for long forms
5. New features that would otherwise take months to integrate into the ERP properly
6. User alerts for pending action items
7. Consistently accessible UI components for ADA employees

## How We Facilitated Procurement

Traditionally, inputting detailed information for each item in their ERP was tedious and time-consuming. For example, entering 500 items would require manually entering various details such as the purchased unit of measure, name, description, UPC, and uploading an image for each item. With approximately 20 or more interactions per item, this task could take hours or even days to complete, not to mention the potential for user input errors.

To streamline this process, we implemented several core features:

1. **Autofill item information**: Instead of manually entering each detail, users can scan the barcode or provide a vendor URL for the item, and the system automatically populates the required information. This feature significantly expedites the procurement process, saving valuable time and reducing the risk of errors.
2. **Data de-duplication**: Detect early on if the user is inputting data already in the system, with overrides in case the user is doing so deliberately (always allow for an escape hatch).
3. **Receipt and invoice scanning**: A powerful scanning function that allows users to snap a photo of their receipt or purchase order using their phone or tablet to automatically extract relevant information such as line items, subtotal, and total. This feature is particularly valuable for users working on job sites or in remote locations with limited access to a desktop.
4. **Spreadsheet-like UI**: This interface behaves like a spreadsheet, complete with type-aheads giving context to each field. It eliminates users' need to search the ERP for related documents. The interface also includes auto-saving forms, inline calculations, and shortcuts.

While continued development has brought more features, these are the ones that proved to be the most valuable in saving users’ time.

<ImageSet
    images={[
        { src: '/articles/case-study-cover-pick1.webp', caption: 'Purchase order form (desktop)' },
        { src: '/articles/case-study-cover-pick2.webp', caption: 'Advanced type-ahead demo with document context' },
        { src: '/articles/case-study-cover-pick3.webp', caption: 'Purchase order form (mobile)' },
    ]}
/>

## Overcoming ERP Integration Hurdles

Early in the project, we were confronted with the question: Do we integrate directly into the ERP or maintain Cover Procurement as a separate app? After careful consideration, we pursued the latter path. More or less to avoid potential unknowns and technical constraints inherent in the ERP.

We introduced an intermediary backend between the ERP and the frontend to implement features not supported by the ERP, such as drafts, user preferences, and single sign-on (SSO) for Google. This design allowed for greater flexibility and extensibility in the future.

Unfortunately, nothing comes without a cost in software engineering. We encountered several challenges when integrating with the ERP. The ERP provided an RPC and REST API, which seemed promising, but upon closer inspection, it became evident that it needed to be more robust.

In particular, bulk API operations were needed but lacking. It hindered our ability to efficiently handle some of the larger operations we had in mind. Since certain operations were required to be atomic and may involve modifying several hundred database rows, we needed to assist Cover’s ERP team in implementing these atomic bulk API endpoints.

## Tech Stack

We selected our tech stack based on our guiding principle of “replaceability.” The goal was to ensure a seamless transition for Cover should they decide to integrate their in-house team. With this in mind, the choice of technologies was simple: Use the technologies we and their in-house team are familiar with. Therefore, Vue, Python, Django REST Framework, and Redis were our picks.

We like to impart some wisdom to any teams we work with as a favor for them sharing their knowledge with us. Two such cases were in their continuous integration pipelines and developer environments on their ERP and Cover Procurement.

### Tightening Feedback Loops

A tight developer feedback loop is crucial for delivering new features efficiently and effectively. The sooner a developer is made aware of an issue in the code, the sooner they can address it. Quickly finding errors is especially true when working with a dynamically typed language like Python, which benefits massively from type hinting with static type analysis. For that reason, we incorporated checks in our continuous integration pipeline against MyPy and Pylint, along with the usual unit and integration test runner checks.

### Containerization for Ease-of-Use

As Cover had yet to undertake projects requiring heavy modification to the ERP, developer environments were manually set up on virtual machines and company machines. To address this challenge and create a reproducible and easy-to-set-up development environment, we containerized these projects using Docker Compose. By containerizing the infrastructure stack (Postgres, Redis, Nginx, etc.), developers could focus more on the codebase rather than spending time on environment setup.

## Nailing Procurement, Together

This was a fun foray into a manufacturing company's procurement process. Cover’s team was extremely helpful in teaching us, and we look forward to continued collaboration with them!

Need a few more eyes on your project or idea? [Drop us a message.](/contact)


Case Study: Cover Procurement


A simple CLI using OpenAI and LlamaIndex to answer questions about your website(s).



We've been experimenting with building a chatbot for our website to answer questions about Logram using LlamaIndex and GPT-4. To make this as simple as possible, we decided the chatbot should scrape every page from this site to build its index. That way, there's no need to maintain two separate knowledge bases. This also allows us to have the bot link to its sources.

This isn't an original idea. [ChatBot](https://www.chatbot.com/) does this well while offering a clean UI on top of it. It's a bit bloated for our purposes, though.

## Quick Start

Here's the GitHub repo: [https://github.com/logram-llc/llmsitechatbot](https://github.com/logram-llc/llmsitechatbot). Feel free to fork or contribute.

<CodeBlock filename="README.md" lang="bash">
{`
\# Install the CLI
git clone https://github.com/logram-llc/llmsitechatbot
cd llmsitechatbot
pip install -e .

\# Copy and then configure config.json
cp config.sample.json config.json

\# Build the index
llmchatbot --config config.json build https://logram.io/sitemap.xml

\# Interact with the LLM through an API
llmchatbot --config config.json serve
curl -X POST http://localhost:8000 \\
-H "Content-Type: application/json" \\
-d '{"message": "Who is behind this company?"}'
`}

</CodeBlock>

## Overview

During `llmchatbot build`, the app essentially:

1. Accepts a sitemap or series of URLs
2. Visits each page with Playwright (to handle any JavaScript)
3. Downloads that web page's content
4. Converts it to markdown
5. And inserts it into a vector index

During `llmchatbot serve`, it exposes a POST-able API endpoint that accept a user's query. Using RAG, the information relevant to the that user's query is pulled from the index and handed off to ChatGPT along with the query itself.

LlamaIndex makes this process dead-simple. Here's a quick snippet demonstrating this:

<CodeBlock filename="demo.py" lang="python">
{`
from os import environ
from llama_index import VectorStoreIndex, ServiceContext, Document
from llama_index.llms import OpenAI

OPENAI_API_KEY = environ['OPENAI_API_KEY']
SOURCE_SITEMAP = 'https://logram.io/sitemap.xml'

\# Recursively scrape the website using \`SOURCE_SITEMAP\`
documents = [Document(text="Website contents", metadata={})]

llm = OpenAI(model="gpt-3.5-turbo", api_key=OPENAI_API_KEY)
service_context = ServiceContext.from_defaults(llm=llm, embed_model="local")
index = VectorStoreIndex.from_documents(documents, service_context=service_context, show_progress=True)

query_engine = index.as_query_engine(
chat_mode="context",
verbose=True,
streaming=True,
system_prompt="Your job is to answer questions about Logram, a small web agency."
)

while True:
streaming_response = query_engine.query(input("\\n> "))
streaming_response.print_response_stream()
`}

</CodeBlock>

If you're interested in better understanding these concepts, [LlamaIndex has an excellent high-level overview](https://docs.llamaindex.ai/en/stable/getting_started/concepts.html).

I doubt we'll develop this much further, but it'd be sweet to have a simple frontend on top of the CLI to manage data sources for the index. Having its API return references in the response body is another nice-to-have.


Chat with Your Website Using LlamaIndex & GPT-4


Quick introduction to Lighthouse CI and how it can be used in your GitHub Actions workflows for CI



I've noticed that despite [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) being one of the most widely used web development tools, Google's [Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci) really isn't used as frequently as I believe it should in CI workflows. Having a decent Lighthouse score is a must for any [accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility), SEO-friendly, performant website. Why shouldn't checks against it sit alongside your lint and type checks?

Following Lighthouse CI's [Getting Started](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md) guide is the easiest way to set it up. There's too many configuration options to discuss, so I encourage you to check that article out.

Essentially, though, you're only dealing with two files: (1) the [Lighthouse configuration file](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md) and (2) your [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows). I've included an example of each below.

<CodeBlock filename="lighthouserc.json" lang="json">
    {`
{
    "ci": {
        // ...
        "assert": {
            "preset": "lighthouse:no-pwa",
            "assertions": {
                "categories:performance": [
                    "error",
                    {
                        "minScore": 0.9
                    }
                ],
                "categories:accessibility": [
                    "error",
                    {
                        "minScore": 1.0
                    }
                ]
            },
            // ...
        }
    }
}
`}
</CodeBlock>

<br />

<CodeBlock filename=".github/workflows/ci.yml" lang="yaml">
{`
name: CI
on:
    pull_request:
        branches:
            - main
concurrency:
    group: $\{\{ github.head_ref || github.run_id \}\}
    cancel-in-progress: true
jobs:
    ci:
        runs-on: ubuntu-22.04
        timeout-minutes: 30
        steps:
            - uses: actions/checkout@v3
            - uses: actions/setup-node@v3
              with:
                  node-version: '18.14.2'

            - name: Install
              run: |
                  npm ci

            - name: Run Lighthouse
              id: lighthouse
              continue-on-error: true
              run: |
                  npx lhci autorun

`}

</CodeBlock>

After setup is complete, all that's left to to do is enter your repo's settings and [add a ruleset](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository) to your default branch that requires `ci` pass before any pull request can be merged.


Incorporating Lighthouse into Your CI Workflows


A simple form backend powered by a Notion database and a Cloudflare Worker


We're excited to introduce [NotiFlare Forms](https://github.com/logram-llc/notiflare-forms), an open-source project that streamlines connecting your forms to a [Notion](https://notion.so/) database using [Cloudflare Workers](https://workers.cloudflare.com/).

When we started this website, we needed an inexpensive server to handle form data from our ["contact us" page](https://logram.io/contact). We didn't want to grapple with a database or an expensive SaaS product (e.g. [Netlify Forms](https://www.netlify.com/products/forms/)). And we couldn't rely on the backend serving this site because it's tied to Cloudflare's limited [Cloudflare Pages](https://pages.cloudflare.com/).

Since Notion powers most of our business and has a convenient [public API](https://developers.notion.com/), we thought that was our best option. After an hour, we had an MVP out:

<CodeBlock lang="typescript">
{`
import { Client } from "@notionhq/client"

function error(errors: string[]): Response {
return new Response(JSON.stringify({ errors, success: false }), {
headers: {
'Content-type': 'application/json'
}
});
}

interface Submission {
name: string;
email: string;
message: string;
databaseID: string;
}

function notionPage({ databaseID, name, email, message }: Submission): any {
return {
parent: {
database_id: databaseID
},
properties: {
"Title": {
"title": [
{
"text": {
"content": 'Form Submission'
}
}
]
},
"Email": {
"email": email
},
"Name": {
"rich_text": [
{
"text": {
"content": name
}
}
]
},
},
children: [
{
"object": "block",
"type": "paragraph",
"paragraph": {
"rich_text": [
{
"type": "text",
"text": {
"content": message
}
}
]
}
}
]
}
}

export default {
    async fetch(
        request: Request,
        env: Env,
        ctx: ExecutionContext
    ): Promise<Response> {
        if (request.method.toUpperCase() !== "POST") {
            return error(["Only POST requests allowed."])
        }

        const formData = await request.formData()
        const name = formData.get("name")
        const message = formData.get("message")
        const email = formData.get("email")

        if ([name, message, email].filter((f: string|null|File) => !f).length > 0) {
            return error(["name, message, and email fields must contain a value."])
        }

        try {
            const notion = new Client({
                auth: env.NOTION_INTEGRATION_TOKEN,
            })

            await notion.pages.create(
                notionPage({
                    databaseID: env.NOTION_DATABASE_ID,
                    name: name as string,
                    email: email as string,
                    message: message as string
                })
            )

            return new Response(null, {
                status: 204,
            });
        } catch(e: any) {
            return error([String(e)])
        }
    },

};
`}

</CodeBlock>

We sought to address two main problem points after the MVP in the project, which [ChatGPT](https://chat.openai.com/) dubbed _"Notiflare Forms"_:

1. Since we can pull the database schema from [Notion's API](https://developers.notion.com/reference/retrieve-a-database), the user should not have to define the schema themselves in code.
2. With `multipart/form-data`, we can support file uploads.

## How NotiFlare Forms Works

NotiFlare Forms uses Cloudflare Workers to manage form submissions, with a Notion database acting as a persistent store. To set it up, create a Notion integration, a Notion database with columns corresponding to your form's fields (or vice-versa), deploy a Cloudflare Worker, and point your form (or request) to the deployed Cloudflare worker.

After configuring the Cloudflare Worker and directing your form to the worker's URL, every valid submission will appear as a new entry in your Notion database.

On a form submission (or really any `multipart/form-data` POST request), NotiFlare Forms will do three primary things:

1. Verify the submission contains the configured `NOTION_REQUIRED_COLUMNS`.
2. Upload any files to an [R2](https://www.cloudflare.com/products/r2/) bucket, if configured.
3. Create a new Notion database entry page.

### Demo

<ImageSet
    images={[
        {
            src: 'https://github.com/logram-llc/notiflare-forms/raw/main/.github/readme/demo.gif',
            caption: 'Demonstration of NotiFlare Forms',
        },
    ]}
/>

In the demo, we used the following HTML form pointed towards our Cloudflare worker. The `Name`, `Message,` and `Attachments` fields correspond to our Notion database's column names.

<CodeBlock lang="html">
{`
<form
  method="POST"
  action="https://our-cloudflare-worker/"
  enctype="multipart/form-data"
>
  <label>
    Name 
    <input type="text" name="Name" required />
  </label>
  <label>
    Message 
    <textarea type="text" name="Message" required></textarea>
  </label>
  <label>
    Attachments 
    <input type="file" multiple="" name="Attachments"/>
  </label>

  <button type="submit">Send</button>
</form>
`}
</CodeBlock>

## Benefits of NotiFlare Forms

    * **Simplicity**: No need to set up and manage servers or databases. NotiFlare Forms takes care of everything for you.
    * **Flexibility**: Design your form however you like and match the column names in your Notion database to your form's field names.
    * **Cost-effective**: Cloudflare Workers and Notion offer free tiers, making it possible to run your form backend without incurring any costs.
    * **Scalability**: Cloudflare Workers can handle many requests, ensuring your form backend can scale with ease.

## Upcoming Enhancements

We're excited about growing and improving this project further. Here are a few enhancements we have in mind for the future:

1. Presently, NotiFlare Forms supports only one Notion database per Cloudflare worker. However, there are no technical limitations that prevent us from accommodating multiple Notion databases.
2. Notion's database API requires a Notion user ID for the `People` column type, and as such NotiFlare Forms expects the same to be submitted through the form. We aim to enable NotiFlare Forms to look up the user ID on Notion when provided with an email address.
3. While we appreciate Cloudflare, it shouldn't be an essential requirement for running this project. As such, we plan to add support for AWS Lambda hosting. We also intend to support all S3-compatible APIs for file uploads to broaden developer options.

## Getting Started

To get started with NotiFlare Forms, head over to the [GitHub repository](https://github.com/logram-llc/notiflare-forms/) and follow the instructions in the README.

---

We'd love to hear your feedback, so if you have any questions or suggestions, please don't hesitate to reach out by creating a [GitHub issue](https://github.com/logram-llc/notiflare-forms/issues) or using our [contact form](/contact)!


Introducing Notiflare Forms



We recently ran into an issue where &mdash; boiled down &mdash; we had two servers:

1. A Node.js server that would authenticate API users via the `Authorization` header. It exposes an `/auth/verify` endpoint, which returns `2xx` if this header is valid.
2. A websocket server we had no control over with no authentication mechanism

How could we expose this websocket server without it being unprotected?

After researching a bit, we found Caddy has a directive called [forward_auth](https://caddyserver.com/docs/caddyfile/directives/forward_auth). We could leverage this to forward all requests to our upstream node server's token verification endpoint before they're passed along (if successful) to our upstream websockets server.

<CodeBlock filename="Caddyfile" lang="typescript">
{`
:9000

forward_auth {$UPSTREAM_NODE_SERVER} {
uri /auth/verify
}

reverse_proxy {$UPSTREAM_WEBSOCKETS_SERVER} {
header_up -Authorization
}
`}

</CodeBlock>

Now, by only exposing our Caddy server, we've essentially added auth to our websocket server.


Logram

Blog

Case Study: Cover Procurement

Chat with Your Website Using LlamaIndex & GPT-4

Incorporating Lighthouse into Your CI Workflows

Introducing Notiflare Forms

TIL: Caddy's forward_auth Directive