I wanted to build an ask-for-help form into an app that my JumboCode team built, in case the client had questions after we handed it off:

But in true fashion, I decided to over engineer it. I thought, What if I had a little site that I could use to generate forms for anything?, and forms.ben.page was born.

I just configure a bit of JSON, and it spits out another page that I can use.

Currently the responses go to LogSnag, but I’m thinking of migrating it to just send me a Discord notification instead.

Look, this was definitely overkill and the chance that I use this again for another form is quite slim. But I had a bit of fun building it! And that’s not a bad outcome.

Greetings from Croatia!

I’m on vacation here with my parents. But in the airport, in the car, and in the evenings, I’ve been tinkering with building a note-taking app.

The idea was for a note-taking app where you can ask an AI assistant questions based on your notes:

How I built it

• Laravel, React (via Inertia)
• A background job periodically extracts new paragraphs from your notes and “embeds” them using OpenAI’s embeddings.
How do embeddings work? (Based on Ben’s very basic understanding)

An embedding takes a piece of text and outputs a vector, an array of 1,536 numbers that identifies a point in 1,536-dimensional space (just like 3 numbers identify a point in 3D space).

Then you can take any two pieces of text that’ve been “embedded” into a vector and calculate how far apart they are (like you could for two points in 3D).

That distance between the two points is how closely related they are — for example, a sentence about “cats” and “pets” would be more closely related than a sentence about “cats” and “mountains”.

• When you ask a question, the app embeds your question and finds the most relevant paragraphs in your notes.
• It feeds these paragraphs into ChatGPT’s API, along with your question, and the AI synthesizes an answer.

meh

I don’t think I’m gonna keep building this.

feature parity

Note-taking apps are a fickle thing to build, and despite this I keep trying to build them. But there’s a ton of features that a note-taking app eventually needs to have to be in line with the myriad of note-taking apps out there.

If I’m going to ask people (starting with myself) to use this app, it needs those features. And I’m the one who’s going to have to build them all, and make them nice.

is this useful?

After thinking about it, I’m not convinced that “ChatGPT for your notes” is a useful concept.

Every use-case I can come up with can be solved by really good search, powered by vector embeddings. But feeding the search results into AI and having it synthesize an answer doesn’t seem to add any value, and costs speed and money for each question.

(If you have ideas of common situations where it would be useful, please let me know!)

And at the end of the day, good search is a feature, not a product. I’m sure Notion and all the others are looking into using embeddings to power their search. I look forward to when that happens.

This is an idea for JumboCode (What is JumboCode?) that is not a particularly good idea, and JumboCode should probably not do it, but I thought it’s interesting nonetheless.

JumboCode builds these free apps for non-profits each school year, but then the club doesn’t maintain them. If clients want improvements or bug-fixes, we don’t do them. It feels like there might be an idea here, but I’ll explain at the end why it’s probably not worth exploring right now.

Maintenance is integral

If you want the organization to keep using the app you built for them, maintenance is super important.

As soon as bugs start cropping up, or they notice features that are missing, it feels like a ticking time bomb: why keep using this software that won’t get improved?

My idea for JumboCode+

My “JumboCode+” idea is that we create an organization to do the maintenance, hiring already-skilled developers, but we charge the clients for our work.

These developers will be experienced in web development; most JumboCode developers are learning web development for the semi-first time (which is fantastic!), but these developers will need to be more experienced since:

1. They’re jumping into an unfamiliar codebase, full of decisions that were made by a team that is no longer reachable.
2. We’re billing the clients for their work.

🤑

The money that JumboCode+ earns could be split between the developers and JumboCode, as a way of funding the club. (The club is also providing the service of finding clients, which justifies its cut.)

And more club funding is always great!

So, why not?

It’s a conflict of interest

1. Building an app for free, but then offering paid maintenance? That sounds a bit like a mafia shakedown.
2. JumboCode is an organization that aims to do philanthropic good. Having an offshoot of the organization that charges money muddies the mission a bit.

It’s not the focus

Personally, I see JumboCode’s mission as two things:

1. Teach students web development (often this means introducing them to it for the first time).
2. Empower student to use their technical skills for good.

Money is nice, but this JumboCode+ idea doesn’t contribute to either of these. It’s something that would take a large amount of effort, and it seems misguided to expend effort here rather than furthering the core mission.

JumboCode is a club at Tufts that builds apps for non-profits.

They’re letting me be the Head of Engineering for it next year! So I figured I’d write one short blog post about what it is, so every time I write about it I can link back here.

The club forms ~9-12 teams of developers who work on teams with 1 project manager, 1 tech lead, and 1 designer. They’re assigned to a non-profit that wants an app or website built.

They spend the whole school year, from September until May, building the app. It gets handed off to the client at the end of the school year, at which point it becomes their responsibility to maintain.

It’s not a super old club — I believe it started in 2015 — but it’s grown to be one of the larger clubs on campus, with 100+ members.