I find interesting that you have added the AI prompt as an example integration guide. Will this become a new trend that products not only provide API, SDK but also prompts for your coding agent of choice.
This really helps if they've had large version changes and the coding agents (without a search) only know about the old docs.
In that sense, adding prompt instructions for Spikelog feels like a natural extension of this trend. I mainly added them to share what worked for me when integrating another product with Spikelog.
> Will this become a new trend that products not only provide API, SDK but also prompts for your coding agent of choice.
It seems like it's becoming the new norm. Two recent examples I've seen: Xcode ships with for-LLM xOS documentation, and Stytch provides for-LLM SDK/API documentation.
Some thoughts:
1) I think you could simplify the onboarding - I don't think I actually need to make an account up front. It somewhat contradicts the way the landing page presents things.
2) The AI prompt does a good job - I really like the output it provides.
3) It doesn't seem like there's a super straightforward way to separate local & production logs - would be nice.
I implemented it - I'll see how it cooks the next couple of days & check back.
Side note, if you want to try that project, since you're a vibe coder, I'd appreciate the feedback too - vibescaffold.dev.
Great, you're the first user then! If don't mind sharing your metrics, feel free to DM me on discord, I've joined yours.
1) Good point, I wanted to avoid the complexity of this for the first version, but you're 100% right, it would be great for someone to try first then upgrade when they register an account.
2) Thanks. Great to hear!
3) The best way to do this right now would be to create a project for each env and then give each env the API key from the corresponding project. Another way could be to put the env in the tags, but I think that's a bit messier as both lines would appear on the same chart (plus I've not even tested that works yet).
vibescaffold.dev looks interesting. Let me spend a bit of time and I'll feed back in your discord.
Yep, that's not ideal... if all the numbers are integers, it would be better if Spikelog recognised the chart as a chart of ints and remove the floating points. Thanks for the feedback!
I used Cursor and Opus 4.5. What made it faster for me was symlinking in a few on-going projects that I've been working on which gave Cursor a reference for how I set things up in these projects.
This substack is pretty new for me, but I'm planning on sharing more things there which may (or may not) help others. Next article there will just be sharing the symlinking setup (not rocket science - but some people don't know ln -s exists).
Poster literally says in the comment you replied to that they used other code they had to speed the development, so no it doesn't appear they wrote it entirely with an LLM, not that would matter if they did as long as it did what it was suppose to do (and what it was suppose to do isn't being defined by a gatekeeper).
They already said they used AI, why ask again? These sorts of comments are unnecessary even when there might be a lack of transparency, which isn't the case here at all.
This looks neat, thanks for building and sharing it.
I do agree that observability stacks are usually a deep pit of things to configure and services to run, but there are tools that simplify things considerably. I can personally vouch for OpenObserve, and I've heard good things about SigNoz as well. They're essentially a single-binary deployment, and all it requires is configuring otel-collector on each machine you want to send data from. I know that OpenObserve has a REST API as well, so you can just send the data via plain HTTP if you prefer to not use OpenTelemetry.
So while I'm sure your project is useful for very simple use cases, it will be difficult to support anything slightly more sophisticated. And you'll have to reinvent the wheel for most of this, of course. But good luck, regardless!
Thank you! and I appreciate the mentions... they’ll definitely be useful for my projects that need more than simple tracking. I might choose to link them instead of Axiom after doing more research into the options!
I’m very aware there are a lot of mature solutions in this space. Almost too much choice - which gave me decision paralysis when my need was simple. I’m not aiming to compete with full observability stacks like that. My goal with this was to intentionally stay on the extremely simple end of the spectrum. I'm aiming for something that’s quick to integrate, easy to understand, and focused on lightweight metrics rather than deep operational telemetry.
I’m also a big fan of Plausible and the idea of making select projects or charts publicly viewable in a dynamic way. Their public dashboard here was a big inspiration: https://plausible.io/plausible.io
I find interesting that you have added the AI prompt as an example integration guide. Will this become a new trend that products not only provide API, SDK but also prompts for your coding agent of choice.
A lot of products are giving some agent instructions as a guide to using them... e.g. https://electric-sql.com/docs/agents
This really helps if they've had large version changes and the coding agents (without a search) only know about the old docs.
In that sense, adding prompt instructions for Spikelog feels like a natural extension of this trend. I mainly added them to share what worked for me when integrating another product with Spikelog.
> Will this become a new trend that products not only provide API, SDK but also prompts for your coding agent of choice.
It seems like it's becoming the new norm. Two recent examples I've seen: Xcode ships with for-LLM xOS documentation, and Stytch provides for-LLM SDK/API documentation.
Nice! Gonna give it a try for my new project.
Some thoughts: 1) I think you could simplify the onboarding - I don't think I actually need to make an account up front. It somewhat contradicts the way the landing page presents things. 2) The AI prompt does a good job - I really like the output it provides. 3) It doesn't seem like there's a super straightforward way to separate local & production logs - would be nice.
I implemented it - I'll see how it cooks the next couple of days & check back.
Side note, if you want to try that project, since you're a vibe coder, I'd appreciate the feedback too - vibescaffold.dev.
Great, you're the first user then! If don't mind sharing your metrics, feel free to DM me on discord, I've joined yours.
1) Good point, I wanted to avoid the complexity of this for the first version, but you're 100% right, it would be great for someone to try first then upgrade when they register an account.
2) Thanks. Great to hear!
3) The best way to do this right now would be to create a project for each env and then give each env the API key from the corresponding project. Another way could be to put the env in the tags, but I think that's a bit messier as both lines would appear on the same chart (plus I've not even tested that works yet).
vibescaffold.dev looks interesting. Let me spend a bit of time and I'll feed back in your discord.
> See Spikelog's own metrics ← Generated with one prompt
Ah, that's why it shows user count (an integer) as a floating point? Or is that an inherent limitation somehow?
Yep, that's not ideal... if all the numbers are integers, it would be better if Spikelog recognised the chart as a chart of ints and remove the floating points. Thanks for the feedback!
How did you go about building this? What was your process, and how did you use AI to aid you?
I used Cursor and Opus 4.5. What made it faster for me was symlinking in a few on-going projects that I've been working on which gave Cursor a reference for how I set things up in these projects.
I also have this method for helping Cursor see the realtime output of services I'm running while developing locally which really speeds things up: https://foundinglean.substack.com/p/the-best-improvement-ive...
This substack is pretty new for me, but I'm planning on sharing more things there which may (or may not) help others. Next article there will just be sharing the symlinking setup (not rocket science - but some people don't know ln -s exists).
So is this app essentially written by an LLM, not by you?
Poster literally says in the comment you replied to that they used other code they had to speed the development, so no it doesn't appear they wrote it entirely with an LLM, not that would matter if they did as long as it did what it was suppose to do (and what it was suppose to do isn't being defined by a gatekeeper).
Coding agents might get there someday, but today they still need quite a bit of assistance.
What appeared as a good faith question, was answered in good faith and of course was later revealed to be a "gotcha" question. It's all so tiring.
"Oh so you drove all the way to my house? You couldn't walk?"
Sorry I simply felt like my question wasn't really answered.
They already said they used AI, why ask again? These sorts of comments are unnecessary even when there might be a lack of transparency, which isn't the case here at all.
This looks neat, thanks for building and sharing it.
I do agree that observability stacks are usually a deep pit of things to configure and services to run, but there are tools that simplify things considerably. I can personally vouch for OpenObserve, and I've heard good things about SigNoz as well. They're essentially a single-binary deployment, and all it requires is configuring otel-collector on each machine you want to send data from. I know that OpenObserve has a REST API as well, so you can just send the data via plain HTTP if you prefer to not use OpenTelemetry.
So while I'm sure your project is useful for very simple use cases, it will be difficult to support anything slightly more sophisticated. And you'll have to reinvent the wheel for most of this, of course. But good luck, regardless!
Thank you! and I appreciate the mentions... they’ll definitely be useful for my projects that need more than simple tracking. I might choose to link them instead of Axiom after doing more research into the options!
I’m very aware there are a lot of mature solutions in this space. Almost too much choice - which gave me decision paralysis when my need was simple. I’m not aiming to compete with full observability stacks like that. My goal with this was to intentionally stay on the extremely simple end of the spectrum. I'm aiming for something that’s quick to integrate, easy to understand, and focused on lightweight metrics rather than deep operational telemetry.
I’m also a big fan of Plausible and the idea of making select projects or charts publicly viewable in a dynamic way. Their public dashboard here was a big inspiration: https://plausible.io/plausible.io
That’s the model I borrowed for Spikelog as well: https://spikelog.com/p/spikelog