DEV Community: Graham McCann

Technical SEO Checks I Run Before Writing More Content

Graham McCann — Sat, 22 Aug 2026 09:01:59 +0000

“We need more content” is one of the most common conclusions in SEO.

Sometimes it is right. Often it arrives too early.

If search engines cannot reliably crawl, understand or index the pages already on a site, another twenty articles just create a larger pile of URLs with the same problem. Before planning content, I run a technical pass in a fixed order.

It is not glamorous, but it stops expensive work being built on a weak base.

1. Check the actual HTTP response

I start with the page itself, outside the browser interface.

curl -I https://example.com/service-page

For an indexable page, I normally expect a clean 200 response. A redirect may be intentional, but chains and loops need attention. A page can also look normal in a browser while behaving like a soft 404 because the content is thin, missing or replaced by an error message.

I check representative URLs from every important template:

the homepage
service and category pages
location pages
articles
paginated pages
filtered or parameterised URLs

One healthy page does not prove that the whole site is healthy.

2. Read the robots and canonical instructions together

A page can be blocked or devalued in several different places:

robots.txt
a meta robots tag
an X-Robots-Tag HTTP header
a canonical pointing somewhere else
an authentication or firewall rule

These instructions need to agree.

A surprisingly common setup is an indexable page with a canonical to the wrong host, protocol or URL variant. I choose one version of the domain, one trailing-slash policy and one protocol, then make internal links, canonicals and sitemap entries use it consistently.

I also check rendered HTML. If a canonical or robots directive is injected by JavaScript, the source and rendered versions may not tell the same story.

3. Treat the sitemap as an inventory, not a repair tool

An XML sitemap helps discovery. It does not force indexing.

I want it to contain canonical, indexable URLs that return 200. Redirects, deleted pages, duplicates and private areas do not belong there.

For a small site, I compare the sitemap against the pages the business actually considers important. This often reveals both problems at once: URLs in the sitemap that should not exist, and valuable pages that have been left out.

A sitemap's lastmod value should also mean something. Updating every timestamp on every deployment teaches crawlers that the field is unreliable.

4. Find pages with no internal route

A URL in a sitemap can still be an orphan.

Search engines learn a great deal from internal links: which pages matter, how topics relate and what language describes a destination. A service page linked from the main navigation and relevant articles has a very different position from one that exists only in an XML file.

I check:

the click depth from the homepage
broken internal links
pages with no incoming links
repeated links to irrelevant pages
anchor text that says nothing about the destination

I do not try to force every page into the navigation. The aim is to create sensible routes a visitor might genuinely follow.

5. Validate structured data against what visitors can see

Structured data is useful when it accurately describes the page. It is not a place to add facts that the page itself does not support.

A basic service business might use Organization, LocalBusiness, Service, BreadcrumbList or FAQPage, depending on the content. The correct type matters less than the truthfulness and consistency of the properties.

I validate the JSON-LD, then manually compare names, URLs, phone numbers, addresses, prices and opening hours with the visible page.

Invalid markup is a technical bug. Valid markup that exaggerates the page is a trust problem.

6. Look at performance by template

A sitewide performance score can hide the useful detail.

The homepage might be fast while every service page loads a huge hero image. Blog posts might shift because an advert or embedded widget has no reserved space. A booking page may respond slowly because it waits on several third-party scripts.

I review the main templates and pay particular attention to:

Largest Contentful Paint, usually the hero image or heading
Interaction to Next Paint, often affected by heavy JavaScript
Cumulative Layout Shift from images, fonts and injected elements
server response time
unused third-party code

The fix is frequently ordinary: resize an image, set dimensions, preload the right font, remove a script or avoid loading a widget before it is needed.

7. Check whether each page has a distinct job

Technical health cannot rescue a group of pages that all answer the same query in almost the same way.

For each important URL, I write down:

the visitor's likely intent
the main topic
the unique information on the page
the action the visitor can take
the closest competing page on the same site

If two URLs have the same answer, I decide whether to combine them, differentiate them or choose one canonical version. Writing more text onto both rarely solves the overlap.

Titles and H1s should be descriptive, but the real test is the body. A page needs to fulfil the promise made in the search result.

8. Verify after changes go live

The audit is not finished when a spreadsheet is delivered.

After deployment, I recheck response codes, canonicals, robots directives, structured data and sitemap entries. I use Search Console's URL Inspection for a sample of important pages and watch crawl or server logs where they are available.

Indexing is not instant, and not every valid page deserves to rank. The goal of the technical pass is narrower: remove accidental barriers and give worthwhile pages a clear, consistent structure.

My short pre-content checklist

Before commissioning more articles, I want to be able to say yes to these questions:

Do priority URLs return the intended status code?
Are they indexable and self-canonical?
Are domain and URL variants consistent?
Does the sitemap list only useful canonical URLs?
Can visitors reach important pages through internal links?
Does structured data match visible information?
Are the main templates usable and reasonably fast?
Does every page have a distinct purpose?
Have the deployed fixes been verified?

Only then do I move on to content planning.

This is the same order I use at GM SEO Services: fix crawl and indexation problems first, then invest in content.

The Hidden Complexity of Appointment Availability

Graham McCann — Sat, 22 Aug 2026 08:44:08 +0000

Appointment booking looks simple until you try to build it.

At first, the problem appears to be:

Read the business opening hours.
Remove times that are already booked.
Show what remains.

That version works for a demo. It does not survive contact with a real therapist, tutor, salon or consultant.

While building OpenSlot, I found that availability is less like a calendar and more like a small rules engine. A time is bookable only when several independent constraints agree.

A slot is more than a start time

A useful slot needs at least:

a start and end time
the service duration
a staff member
the business time zone
minimum booking notice
buffers before or after the appointment
working hours and breaks
time off
existing bookings

I keep the service duration separate from its buffers. A 60-minute consultation with a 15-minute clean-up period occupies 75 minutes of the diary, but the customer should still see a 60-minute service.

A simplified rule might look like this:

function canBook(slot, service, schedule, existingBookings) {
  const occupiedUntil = addMinutes(
    slot.start,
    service.duration + service.bufferAfter
  );

  return (
    isInsideWorkingHours(slot.start, occupiedUntil, schedule) &&
    hasEnoughNotice(slot.start, service.minimumNotice) &&
    !overlapsTimeOff(slot.start, occupiedUntil, schedule.timeOff) &&
    !overlapsBooking(slot.start, occupiedUntil, existingBookings)
  );
}

The code is not the difficult part. The difficult part is agreeing on what every boundary means.

If one appointment ends at 11:00, can the next start at 11:00? Usually yes, unless a buffer applies. Are end times inclusive or exclusive? Pick one convention and use it everywhere. I use half-open ranges: the start is included and the end is not.

That makes adjacent bookings legal without special cases:

09:00 <= appointment < 10:00
10:00 <= next appointment < 11:00

Generate candidates, then reject them

I had better results by generating possible start times first and passing each one through the rules.

For example, a staff member works from 09:00 to 17:00 and the booking interval is 30 minutes. Generate 09:00, 09:30, 10:00 and so on. Then reject candidates that fail a constraint.

This is easier to reason about than trying to build one enormous database query that accounts for every rule at once. It also makes tests readable:

expect(slotsFor("2026-09-11")).not.toContain("09:00"); // time off
expect(slotsFor("2026-09-11")).toContain("11:30");    // available
expect(slotsFor("2026-09-11")).not.toContain("16:30"); // runs past closing

The last case catches an easy mistake. A 60-minute service cannot start at 16:30 just because the start time falls within working hours.

Time zones are a display concern and a business rule

Store timestamps in UTC, but do not pretend that solves time zones.

The business defines availability in its own local time. A customer may view that availability from somewhere else. Daylight-saving changes mean “every Monday at 09:00” cannot safely be represented as “add seven lots of 24 hours”.

The process I use is:

Interpret working hours in the business time zone.
Build the local date and time for the requested day.
Convert candidate timestamps to UTC for comparisons and storage.
Display them in the correct customer or business context.

DST transition days deserve explicit tests. They are rare enough to be forgotten and common enough to break production calendars twice a year.

Preventing double bookings requires an atomic write

Removing occupied times from the page is only the first defence.

Two customers can load the same available slot, wait, and submit within milliseconds of each other. Both browsers are telling the truth based on the data they received.

The server must check availability again while creating the booking. That check and insert need to happen atomically, using a transaction, lock or database constraint appropriate to the schema.

The important rule is simple:

The availability shown in the browser is helpful. The database is authoritative.

I also use an idempotency key around booking creation. If a customer double-clicks or a request is retried, the same intent should not create two appointments.

Payment status is not booking status

A paid booking can be confirmed, pending, cancelled or refunded. A confirmed booking can be free or paid later.

Combining these into one status field creates awkward states surprisingly quickly. I keep them separate:

booking_status: pending | confirmed | cancelled
payment_status: not_required | pending | paid | refunded | failed

This makes webhook handling much less fragile and keeps the diary understandable when a payment provider is slow.

The boring cases are the real product

The happy path makes a good screenshot. The product is everything around it:

a staff member takes the afternoon off
a service needs a longer buffer
a customer retries payment
the clocks change
two people choose the same time
an appointment is moved rather than cancelled

That is why booking software is a good engineering exercise. The interface can remain simple only because the underlying rules are precise.

I built OpenSlot around that idea: customers should see a clear choice of useful times, while the business keeps control of the rules behind them.

I Built a Simple Solana Wallet Export Tool Because Existing Ones Were Frustrating

Graham McCann — Thu, 21 May 2026 17:32:40 +0000

I Built a Simple Tool to Export Phantom Wallet Transactions Without Coding

If you’ve ever tried exporting transaction history from a Solana wallet, you’ve probably discovered two things pretty quickly:

Most wallets don’t make it easy
Crypto tax tools can get expensive fast

That frustration is exactly why I built Export My Wallet.

The goal was simple:

Paste a wallet address, export the transactions, and move on with your life.

No account creation. No complicated setup. No syncing exchanges for 45 minutes only to discover half the transactions are missing.

Just a straightforward export tool for Solana wallets.

The Problem I Kept Running Into

I work on Solana projects regularly, and I kept needing transaction exports for things like:

Tax calculations
Tracking token launches
Checking wallet activity
Looking back through old trades
Auditing transfers between wallets

The existing options were either:

overly complicated,
painfully slow,
or locked behind expensive subscriptions.

Some platforms also tried to become your entire portfolio tracker when all you actually wanted was:

“Give me my transactions in a usable format.”

So I decided to build a lightweight alternative.

What the Tool Does

With https://www.exportmywallet.com, you can:

Export Solana wallet transactions
Download CSV files
View transaction history quickly
Check token transfers
Pull data for accounting or tax software

It works with wallets like:

Phantom
Solflare
Backpack
and any public Solana address

You don’t even need to connect your wallet if you don’t want to. You can simply paste the address.

That was important to me.

A lot of users are understandably cautious about connecting wallets to random websites. Public-address lookup avoids that entirely.

One Thing I Wanted to Avoid

I didn’t want the site to feel like “crypto SaaS bingo”.

You know the type:

giant dashboards,
ten upsells,
dark patterns everywhere,
AI-generated marketing copy talking about “revolutionising finance”.

I just wanted a utility that solved a problem cleanly.

Fast input. Fast export. Minimal friction.

Sometimes boring software is the best software.

Technical Challenges

Solana transaction history can get messy surprisingly quickly.

A few things that made development interesting:

Pagination and RPC limits

Large wallets can have thousands of transactions. Pulling historical data efficiently without hammering RPC endpoints took a fair bit of optimisation.

Token metadata

Not every token behaves nicely. Some older tokens have incomplete metadata, weird decimals, or broken symbols.

Wallet parsing

Simple SOL transfers are easy.

DeFi interactions, NFT movements, swaps, and token account changes are not.

Especially when users expect a clean CSV at the end.

What Surprised Me Most

Honestly?

How many people just want simpler crypto tools.

Not everyone wants advanced analytics or trading terminals.

A lot of users simply want:

clarity,
exports,
transparency,
and tools that don’t feel hostile to use.

That’s probably the biggest thing I’ve learned building in crypto so far.

Future Plans

A few things I’m working on next:

Better transaction categorisation
Multi-chain exports
Cleaner tax-ready formatting
Faster large-wallet processing
More export formats

I’m also experimenting with other lightweight crypto utilities alongside this project.

To Round This Up ...

Crypto tooling still has a usability problem.

There are amazing protocols and ecosystems underneath it all, but basic tasks can still feel harder than they should.

I’m hoping this tool helps make one small part of that experience easier.

If you want to try it, the site is:

https://www.exportmywallet.com/

Create a Solana Token in 2 Minutes (No Code, No Setup, No Headache)

Graham McCann — Sat, 18 Apr 2026 20:40:13 +0000

If you’ve ever tried to create a token on Solana, you’ll know how it usually goes…

You start with a simple idea.

Then suddenly you’re installing tools, reading docs, and staring at a terminal wondering what just broke.

Most guides assume you’re a developer. If you’re not, it’s a painful way to spend an afternoon.

The problem

Most people hit the same walls:

You need to install and configure multiple tools
Token creation involves command line steps
One small mistake = confusing errors
It takes way longer than it should

For something that should take minutes, it ends up feeling like a mini project.

What I built

So I built something simpler:

👉 https://www.solana-token-creator.com

A tool that lets you create a Solana token in minutes, without writing any code.

You just:

Connect your wallet
Enter your token details
Confirm the transaction

That’s it.

A real example

Let’s say you want to test an idea for a token called TESTCOIN.

Normally you’d:

Install the Solana CLI
Create a mint
Set decimals
Mint supply
Handle metadata separately

With this, you:

Open the site
Enter the name, supply, decimals
Click create
Approve in your wallet

And it’s done.

No setup. No messing about.

What it includes

The tool handles:

SPL token creation
Supply + decimal configuration
Minting directly to your wallet
Basic token setup

It’s built to do one thing well.

When you’d actually use this

You’ll likely use something like this if you’re:

Launching a meme coin
Testing a token idea
Building a small Web3 project
Learning how Solana tokens work

Or just experimenting without committing to a full dev setup.

What it doesn’t do (important)

This won’t make your token successful.

It doesn’t:

Add liquidity
Get you holders
Market your project
Build trust

Creating the token is the easy part. Everything after that is where things get interesting.

Why this approach

I didn’t want another bloated Web3 tool.

The goal was:

Fast
Simple
No coding required
No unnecessary steps

Just something that works when you need it.

Feedback welcome

If you’ve tried creating tokens before and hit issues, I’d be interested to hear what slowed you down.

Also open to ideas for improvements that would actually make this more useful.

Exporting Solana Wallet Transactions to CSV (Without the Headache)

Graham McCann — Sat, 18 Apr 2026 20:30:59 +0000

Exporting Solana Wallet Transactions to CSV (Without the Headache)

If you’ve ever tried to export transaction data from a Solana wallet, you’ll know it’s not exactly straightforward.

Explorers like Solscan are great for browsing, but not so great when you actually need clean, structured data you can use.

The problem

Most people hit the same issues:

No simple way to export full transaction history
Data is hard to work with (especially for taxes or analysis)
Existing tools are either overcomplicated or expensive

If you just want a clean CSV of your wallet activity, it ends up taking way longer than it should.

What I built

I built a simple tool called Export My Wallet that does one thing well:

👉 Converts any Solana wallet into a clean CSV in seconds

You just:

Enter a wallet address
Wait a few seconds
Download the CSV

That’s it.

What it includes

The export covers:

Full transaction history
Swaps and transfers
Token activity

It’s designed to be immediately usable for:

Tax reporting
Tracking activity
Portfolio analysis

When you actually need this

You’ll likely need a CSV export if you’re:

Preparing crypto tax reports
Tracking wallet activity over time
Analysing trading behaviour
Keeping records for accounting

Most tools don’t make this easy, especially on Solana.

Why this approach

I didn’t want to build another “all-in-one crypto dashboard”.

The goal was:

Fast
Simple
No wallet connection required
No unnecessary complexity

Just a tool that solves a very specific problem well.

Try it

👉 https://www.exportmywallet.com

Feedback welcome

If you’ve run into similar issues exporting wallet data, or you’ve got ideas for improvements (filters, date ranges, token-specific exports), I’d love to hear them.

I built a Web3 tools directory because everything is scattered

Graham McCann — Tue, 17 Mar 2026 17:57:11 +0000

I built a Web3 tools directory because everything is scattered

Creating anything in Web3 is weirdly harder than it should be.

Not because of the tech itself, but because everything you need is scattered everywhere.

You find one tool on Twitter, another buried in a GitHub repo, then a random blog post from 2021 that might still be relevant… or might not.

It slows everything down.

The problem

If you're building in Web3, you've probably experienced this:

You need a tool for something specific
You search Google and get outdated results
You check Twitter and find threads with half-broken links
You dig through GitHub repos with little context

There’s no single place that feels reliable or complete.

Everything is fragmented.

And when you're trying to build something quickly, that fragmentation becomes friction.

Why this matters

In most industries, tools are easy to find.

You’ve got directories, marketplaces, comparison sites.

In Web3, it’s still messy.

That means:

More time searching
Less time building
More duplication of effort
Missed tools that could actually help

It shouldn’t be like that.

What I built

So I built Web3ToolLaunch.

👉 https://www.web3toollaunch.com/

It’s a simple directory focused on one thing:

Making Web3 tools easier to discover.

What you can do with it

Right now you can:

Browse tools by category
Explore areas like DeFi, AI crypto, NFT and infrastructure
Discover tools you probably wouldn’t have found otherwise
Submit your own tool

No accounts required, no friction.

Just a clean list of tools that are actually useful.

How it’s different

I’m not trying to build another bloated marketplace.

The focus is:

Simplicity
Discoverability
Clean structure
Useful categories

Over time, the goal is to make this a go-to place when you're starting a new Web3 project.

Early challenges

A few things became obvious straight away:

1. Seeding content

A directory is only useful if it has content.

So the early phase is manually adding tools and making sure the categories make sense.

2. Quality vs quantity

It’s tempting to add everything.

But a directory full of low-quality tools is worse than a smaller, curated one.

3. Getting submissions

The real growth comes when other founders start submitting their tools.

That’s the next big step.

What’s next

I’m planning to:

Expand categories (more specific niches)
Add better filtering and sorting
Highlight featured tools
Improve SEO pages for each category

Long term, I want this to become a proper resource for developers and founders building in Web3.

And Finally ...

Web3 has no shortage of tools.

What it lacks is organisation.

That’s what I’m trying to fix.

If it saves someone a bit of time, it’s already worth it.

How to Create a Solana NFT Without Writing Any Code

Graham McCann — Sat, 14 Mar 2026 08:20:57 +0000

Creating a Solana NFT Without Writing Any Code

If you've ever tried minting an NFT on Solana from scratch, you'll know the process can feel a bit technical at first. Between generating metadata, uploading files to decentralized storage, and preparing the mint transaction, there are quite a few moving parts.

The good news is that you don't necessarily need to write scripts or interact with CLI tools anymore. There are now simpler ways to create NFTs on Solana that handle the technical parts for you.

This guide explains how Solana NFTs work and how you can create one without needing to write any code.

What Makes a Solana NFT Different?

A Solana NFT is simply a token on the Solana blockchain that represents a unique digital item. That item might be artwork, a collectible, music, or even access to a community.

Unlike regular tokens, NFTs contain metadata describing the asset. This metadata includes information such as:

the NFT name
a description
the image or media file
optional attributes or traits

The metadata is usually stored outside the blockchain on decentralized storage such as IPFS or Arweave. The NFT token itself simply references that metadata.

Example NFT Metadata

A typical Solana NFT metadata file looks something like this:

{
  "name": "Example NFT",
  "symbol": "NFT",
  "description": "Example Solana NFT metadata",
  "image": "https://example.com/image.png",
  "attributes": [
    {
      "trait_type": "Background",
      "value": "Blue"
    },
    {
      "trait_type": "Eyes",
      "value": "Laser"
    }
  ]
}

When the NFT is minted, the token points to this metadata file. Marketplaces then read the metadata and display the NFT image, traits, and description.

The Traditional Minting Workflow

Developers who mint NFTs manually usually follow a process like this:

Create the artwork or digital asset
Write the metadata JSON file
Upload files to IPFS or Arweave
Use Solana tools to mint the token
Verify the NFT on a marketplace

For developers this process is manageable, but for creators or beginners it can feel unnecessarily complicated.

A Simpler Way to Create Solana NFTs

These days many people use web-based tools that automate most of the process.

Instead of preparing metadata and scripts yourself, the tool generates the metadata, uploads files, and prepares the mint transaction automatically.

For example, this tool allows you to create and mint NFTs directly from your browser:

Solana NFT creator

The idea is straightforward: you upload your artwork, enter the NFT details, and the platform handles the technical steps behind the scenes.

Why Many NFT Projects Use Solana

Solana has become popular for NFT projects for a few practical reasons:

transaction fees are extremely low
confirmation times are very fast
the ecosystem of NFT marketplaces is growing

Because minting costs are so small compared to other blockchains, Solana is often used for experimental collections or new creator projects.

Where Solana NFTs Are Sold

Once minted, Solana NFTs can be listed on marketplaces such as:

Magic Eden
Tensor
Solanart

These platforms allow creators to sell NFTs and collect royalties from secondary sales.

To Wrap Things Up ...

Creating NFTs on Solana used to involve several technical steps, especially around metadata and minting scripts.

Today, tools exist that simplify the workflow so creators can focus more on the artwork or project itself rather than the infrastructure.

If you're curious about the Solana NFT ecosystem, the easiest way to understand it is simply to try minting one and see how the process works.

How I Create Solana Tokens Without Writing Any Rust

Graham McCann — Thu, 05 Feb 2026 13:13:05 +0000

Creating a Solana Token Without Wrestling With the Tooling

Creating a Solana token sounds simple until you actually try it.

You read the docs, install half the internet, argue with Rust versions, get lost in SPL token flags, and somehow still end up wondering if you’ve accidentally given mint authority to the void.

I kept seeing the same questions pop up in Solana and Web3 dev spaces:

How do I mint a Solana token quickly?
Do I need to write Rust for this?
How do I handle metadata properly?
How do I avoid messing up supply or authority?

So I built a small tool that does one thing well: it lets you create a Solana token cleanly, without touching Rust or CLI tooling.

The Flow Is Simple

Connect your wallet
Set the token name, symbol, supply and decimals
Add metadata if you want it
Mint the token

No test scripts.

No local builds.

No copy-pasting commands you don’t fully trust.

What Happens Under the Hood

Under the hood it still follows standard Solana token behaviour.

That means:

Mint authority is explicit
Freeze authority is visible
Supply configuration is clear
Metadata is handled properly

Nothing hidden, nothing magical. Just a cleaner interface for the standard token process.

Why I Built It

Originally I built the tool for my own launches.

After a while a few other developers started using it too, mostly for:

quick experiments
MVP projects
early-stage token ideas

Sometimes you just want to spin up a token and move on to the interesting part of the project.

The Tool

If you're curious, you can try it here:

https://www.soltokenlaunch.com

It's not meant to replace custom Solana programs or serious on-chain development. It simply removes the friction when you want to create a token quickly without building the entire infrastructure stack first.

Curious About Other Workflows

If you're already deep into Solana development, I’d be genuinely interested to hear how you handle token creation in your own workflow.

Do you rely on CLI tooling, custom scripts, or something else?

DEV Community: Graham McCann

Technical SEO Checks I Run Before Writing More Content

1. Check the actual HTTP response

2. Read the robots and canonical instructions together

3. Treat the sitemap as an inventory, not a repair tool

4. Find pages with no internal route

5. Validate structured data against what visitors can see

6. Look at performance by template

7. Check whether each page has a distinct job

8. Verify after changes go live

My short pre-content checklist

The Hidden Complexity of Appointment Availability

A slot is more than a start time

Generate candidates, then reject them

Time zones are a display concern and a business rule

Preventing double bookings requires an atomic write

Payment status is not booking status

The boring cases are the real product

I Built a Simple Solana Wallet Export Tool Because Existing Ones Were Frustrating

I Built a Simple Tool to Export Phantom Wallet Transactions Without Coding

The Problem I Kept Running Into

What the Tool Does

One Thing I Wanted to Avoid

Technical Challenges

Pagination and RPC limits

Token metadata

Wallet parsing

What Surprised Me Most

Future Plans

To Round This Up ...

Create a Solana Token in 2 Minutes (No Code, No Setup, No Headache)

The problem

What I built

A real example

What it includes

When you’d actually use this

What it doesn’t do (important)

Why this approach

Feedback welcome

Exporting Solana Wallet Transactions to CSV (Without the Headache)

Exporting Solana Wallet Transactions to CSV (Without the Headache)

The problem

What I built

What it includes

When you actually need this

Why this approach

Try it

Feedback welcome

I built a Web3 tools directory because everything is scattered

I built a Web3 tools directory because everything is scattered

The problem

Why this matters

What I built

What you can do with it

How it’s different

Early challenges

1. Seeding content

2. Quality vs quantity

3. Getting submissions

What’s next

And Finally ...

How to Create a Solana NFT Without Writing Any Code

Creating a Solana NFT Without Writing Any Code

What Makes a Solana NFT Different?

Example NFT Metadata

The Traditional Minting Workflow

A Simpler Way to Create Solana NFTs

Why Many NFT Projects Use Solana

Where Solana NFTs Are Sold

To Wrap Things Up ...

How I Create Solana Tokens Without Writing Any Rust

Creating a Solana Token Without Wrestling With the Tooling

The Flow Is Simple

What Happens Under the Hood

Why I Built It

The Tool

Curious About Other Workflows

Related Reading