# <a href="https://pourtle.com" style="color:rgb(78, 158, 237);; font-weight: inherit; text-decoration: underline;">Pourtle</a>'s Backstory
\
This isn't a startup, but it was fun to give this project one of those startup-y names. Find a word that feels related to your product in some way, then mess with it a little bit to create a spelling that resembles that word. But it cannot be directly that word. Something something cool factor.

Spoiler, I thought of **portal** first as my relevant word. A few hours of creative brainstorming, ideation, and long discussion, and Pourtle was born. It's like it was meant to be.

Why is portal relevant though? What is this?

I consider myself technologically savvy. Growing up, my dad brought internet to our house in 1997. I've had Facebook since 2007. Smart phones since 2009 (shout out Palm Pre). Dropbox since 2010. And a software engineering - related degree since 2015. The diploma says Electrical Engineering but there was a lot of coding within that curriculum.

All that, and **I still struggle to move my digital content between my devices**. I can't tell you the amount of times I've sent myself a photo on Facebook Messenger to get a picture from my iPhone onto my PC. Or a blob of text that I needed to copy/paste. OR A URL! Just enthusiastically remembered that use case and it's a constant pain point. Facebook Messenger for whatever reason has been the lightest weight mechanism I use to do this which is now a habit.

This isn't unchartered territory though. Apple demonstrates masterclass in this problem space, as long as you use Apple products. A number of cloud services with names containing "Box" or "Drive" exist for this as well. My last project at Microsoft even aimed to solve this.

There's always a catch though. Some quid pro quo. Whether that's monetary, advertisement mind share, data collection, etc. You're valuable and companies take a little bit of your value in exchange for the value they provide. There's nothing wrong with that, it's the basis of business. But in my experience, that requirement has always surfaced through an elongated user experience to accomplish the goal of moving content.

_Sign-in's, downloads, installs, uploads, sign-ups, syncs, etc. etc._

There's also often the compromise of sharing your content with a company. Letting them see it, letting them process it, letting them store it. Privacy is front and center in a lot of ways at a lot of companies, but things can and do go wrong. Hackers are unfortunately good at their jobs and attacks or leaks make headlines every now and then.

Okay, enough spotlighting what is not the biggest problem the world is facing today. The existing solutions are good enough for most and I put up with them from time to time. Let me bookend this section.

I saw an opportunity for a fun project that adds regular and simple value to my life. I have a lot of devices and a lot of content across those devices. And I fairly often need to move my content between my devices. So I built myself (and any of you that want to try it) a connection between my devices to move my content.

Like a portal. Sorry, pourtle **.
 
 

# Overview
\
**30 second elevator pitch! Read quick!**

Need to move a photo, file, link, or more between your phone and computer?

1. Go to [pourtle.com](https://pourtle.com) on your computer
2. Click Get Started and scan the QR code with your phone's camera
3. Your phone and computer are connected! Share whatever between the two devices

No accounts, no uploads, no storing your content somewhere in the cloud. Just a direct connection between your devices to move your content. When you're done, just close out of it and know all your content remains only on your devices.

![Screenshot of Pourtle user experience](/blog/2025-07-23-introducing-pourtle/ux.png)
<figcaption style="text-align: center; font-size: 0.98em; color: #aaa; margin-top: 0.5em;">
 Pourtle user experience as seen on both computer and phone
</figcaption>
 
 

# Technically Speaking
\
One of my favorite things about software engineering is the ability to imagine something, and then just build it. It can sometimes feel like creating art out of logic, and more often than not the only resource required is time.

The more you do this though, the more you realize how frameworks can expedite that process and hone in your thinking to a high-quality solution. I lean into that here.

## First Principles

I approached this space from first principles.

**Problem**: Your content may exist on one device when you have a one-off need for it on a different device.

**Conventional thinking**: Cloud-based, account-based, or closed-ecosystem solutions are standard

### Step 1: Question the Assumptions

1. **Why are cloud solutions popular?** For repeated access on multiple devices
2. **Why are accounts required?** For cloud access and/or business value 
3. **What is the minimum technical solution that could solve this?** A direct data connection between two devices

### Step 2: Break Down the Requirements

* **One-time transfer** – No need for repeated access or persistent storage
* **Cross-platform** – Must work across all platforms and devices (with internet)
* **No friction** – No downloads, no sign-ups, no learning curve
* **Privacy** – Content shouldn't leave a user's devices

### Step 3: Explore the Technical Landscape

Browsers are one of the common denominators across all personal computing devices with internet access and are user expectation. This spans phones, tablets, and PCs, which are also the surfaces most often used to interact with your content.

Examining browser technologies and what could be leveraged, the industry-standard **WebRTC** peer-to-peer protocol appeared as the perfect candidate for a real time, secure data connections directly between devices.

It's not an out of the box solution though, rather an interface of common functionality that (essentially) all browsers implement and make available to applications for consumption. The application layer atop it has a few responsibilities:
- **Signaling** – Coordinate the initial handshake between peers (offer/answer exchange)
- **Connection management** – Handle ICE candidate exchange and connection state
- **Data channel setup** – Establish the bidirectional data pipe for file transfer
- **File chunking** – Break large files into manageable pieces for reliable transfer
- **Error handling** – Gracefully manage network issues and connection drops
- **Session management** – Generate unique session codes and validate peer connections

Those application requirements felt achievable and equally a fun learning challenge for me. I had not previously worked with WebRTC but came away eager to get my hands dirty. Onwards.

### Step 4: Define the Solution

With the work cut out for me above, I dove into defining how this will actually look in code.

#### The Web App

The overarching solution is comprised within web technology to leverage the browser's WebRTC functionality, and served as a web app from the domain pourtle.com. While multiple web frameworks and hosting solutions could've been chosen, I sided with a stack familiar to me:
- **React**: open-source front-end JavaScript library optimized for user interfaces
- **JavaScript**: the programming language used with React (note TypeScript could have also been used)
- **Material UI**: React component library implementing Google's Material Design Language
- **AWS S3/CloudFront**: Static web hosting with a global CDN to distribute

Contained within this web application are my WebRTC implementations for the user experience, connection management, setup, file chunking, and error handling. Sparing the nitty gritty details, some clean layering is in place to provide the UI layer with a simple messaging abstraction to send and receive a file, photo, or text. 

#### Backend Service

The most ambiguous piece which I'd like to focus on entails building the signaling channel paired with the session management. The WebRTC protocol entails an initial handshaking sequence that is established on an external transport (as the WebRTC connection doesn't exist yet).

First, let's establish roles. Every Pourtle session consists of two devices. One acting as a **creator** (starts the session, gets a 6-digit code) and one acting as a **joiner** (enters that code).

##### The Flow

1. **Creator** device visits pourtle.com → backend generates unique session code → code displays on screen
2. **Joiner** device scans/enters code on pourtle.com → backend matches with creator device → both devices know they found each other
3. **Handshake begins** → devices exchange WebRTC setup messages _through_ my backend
4. **WebRTC connects** → backend steps aside, devices talk directly

##### The Architecture

Admittedly I'm cheap when it comes to projects like these. Why pay Amazon for a server to run 24/7 that I use <10 times per month when I could instead pay them for Prime and HBO Max (with ads)? **AWS Lambda + API Gateway WebSockets** means I only pay when someone's actually connecting devices. Widely known as a serverless architecture.

There's a stateful piece to this too. This state lives in **DynamoDB**:
- Creator starts session → store `{sessionCode: "123456", creatorId: "abc"}` 
- Joiner enters code → update to `{sessionCode: "123456", creatorId: "abc", joinerId: "xyz"}`
- Now when "abc" sends a message, the backend can relay it to "xyz".

This relay messaging allows them to exchange WebRTC handshake info, and upon completion the backend becomes irrelevant. Direct peer-to-peer connection takes over. **Aka WebRTC!**

I'm a visual learner, in case you are too:


```mermaid
sequenceDiagram
 participant A as Device A (Creator)
 participant WS as Lambda + API Gateway + WebSocket
 participant DB as DynamoDB
 participant B as Device B (Joiner)

 Note over A,B: Initial Session Setup
 A->>WS: init (no code)
 WS->>DB: PUT SessionCode + ConnectionId[A]
 WS-->>A: 6-digit session code
 
 Note over A: User shares code with Device B
 
 B->>WS: init (sessionCode)
 WS->>DB: UPDATE ConnectionIds += [B]
 WS-->>B: "joined session"
 
 Note over A,B: Peer Readiness Signaling
 A->>WS: signal {type: "ready"}
 WS-->>B: relay ready signal
 B->>WS: signal {type: "ready"} 
 WS-->>A: relay ready signal
 
 Note over A,B: WebRTC Handshake (SDP Exchange)
 A->>A: Create RTCPeerConnection + DataChannel
 A->>A: Generate SDP offer
 A->>WS: signal {type: "offer", sdp: offer}
 WS-->>B: relay offer
 
 B->>B: Create RTCPeerConnection
 B->>B: Set remote description (offer)
 B->>B: Generate SDP answer
 B->>WS: signal {type: "answer", sdp: answer}
 WS-->>A: relay answer
 A->>A: Set remote description (answer)
 
 Note over A,B: ICE Candidate Exchange
 A->>WS: signal {type: "ice", candidate: candidate1}
 WS-->>B: relay ICE candidate
 B->>WS: signal {type: "ice", candidate: candidate2}
 WS-->>A: relay ICE candidate
 
 Note over A,B: Direct P2P Connection Established
 A->>B: RTCDataChannel open
 B->>A: RTCDataChannel open (bidirectional)
 A->>WS: Close WebSocket (optional cleanup)
 B->>WS: Close WebSocket (optional cleanup)
 
 Note over A,B: File Transfer (P2P Only)
 A->>B: File chunks over DataChannel
 B-->>A: Progress acknowledgments
```
 
 

#### Conscious Design Decisions

I am intentionally omitting the use of a [TURN server](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) at this point. 

This equates to **devices must be on the same network to share content**.

My reasoning for this choice:
1. **Cost**: a TURN server would add compute cost and while valuable, again I'm already paying for HBO Max (with ads).
2. **Use cases**: a user's devices (particularly mine) are very frequently on the same network, where there is no need for a TURN server in the first place
3. **Privacy**: Content is more secure given it is not traversing across networks.
4. **Complexity**: [K.I.S.S.](https://en.wikipedia.org/wiki/KISS_principle), no pressing need

This is not an irreversible decision. A TURN server could be added in some day if it made sense.

### Step 5: Write the code
![Screenshot of Pourtle coding session](/blog/2025-07-23-introducing-pourtle/coding.png)

Feel free to check it out! [Repo](https://github.com/afisch710/quick-relay)

## I Love Feedback

Thanks for taking the time to read this post and hopefully you had a chance to play around with [pourtle.com](https://pourtle.com). If you notice any issues, have any feedback, or just want to have a conversation, you can absolutely reach out to me at any of the social links below.
 
 
Cheers!

Introducing Pourtle

## Why? My Goals And Philosophy

If I'm going to talk the talk, I better walk the walk.

I built **alexfischman.dev** not only to highlight my technical passions and history, but to equally showcase my software engineering acumen/prowess and how I prioritize building secure, stable, simple software. The proof is in the pudding (aka the [repo](https://github.com/afisch710/alexfischman.dev)).

This site was thoughtfully and intentionally crafted to be fast, cheap, scalable, reliable and maintainable. Layer that with a delightful UX and you can check off a majority of the "good software checklist".

The goal of this post is to shed some light on how I navigated the lifecycle of this site, from ideation to production.

## Deciding Your Tech Stack

The upfront investment of carefully planning out your tech stack is always worth it. Shortcuts or blissful ignorance at this stage will almost certainly lead to pain, which can surface through your wallet, your sanity, or your success. Now there is an argument that stack sacrifices can and maybe should be made at the start when time is your most valuable resource in a market share race, but I don't anticipate this website becoming the next Unicorn in Silicon Valley so I am not taking that route.

To reiterate my requirements for this website:
- Fast
- Cheap
- Scalable
- Reliable
- Maintainable

Fast, cheap and scalable may have been an oxymoron in days past, but a lot of smart people have spent a lot of time delivering solutions that marry these together in the form of the cloud. I openly admit that **AWS** is the most developer friendly (in my opinion) and it is my platform of choice when investing in new projects/ventures.

Delving into the AWS world's vast catalog of services and my own past experience, my go to choice for a fast, cheap and scalable web experience is to statically host a site in **S3** and leverage **Cloudfront** as a CDN. This can totally eliminate the need for cloud compute while providing low latency access to your content worldwide.

Reliability and maintainability typically are a balance between adopting mature frameworks/technologies and then developing atop them with a proper technical design. My go-to's here are **Next.js (React.js) and TypeScript**. It's a widely supported stack that I am very familiar with.

Let's dive deeper.

### Frontend Stack

I find **Next.js** and the Pages router to be a great balance of developer experience and good perf. It's a relatively simple way to map a file system to routes. Next.js's SSG (static site generation) is an excellent choice for generating page HTML at build time and aligns easily with the static hosting in S3. The build-generated HTML can simply be uploaded to and then served out of the bucket with relatively small configuration and no server need.

As you may know, Next.js is a **React** framework. The React library provides an excellent abstraction for view-centric development and is a well established and supported at this point.

Truth be told, this was my first time using **TypeScript** extensively in a large project. My rationale for doing so was primarily to enable a type-safe and modern codebase, and secondarily to start growing these muscles and broaden my experience. I was pleasantly surprised with the language and it has a bright future ahead of it, as a new native compiler (Go-based) is in active development and will offer 10x faster compilation times.

I historically have been a fan of Google's **Material Design** language and appreciate it's sleek and modern look and feel. That led me to leveraging **Material-UI v6**, the open-source React implementation of Material Design. I have past experience with this and will continue to advocate it is a good choice to build a consistent and pleasant Web UX in a simple manner.

I bundle in the Emotion library and Framer Motion library for some added animations throughout the UX.

### Blog Stack

When it comes to my blog, I initially was a little unsure of what route to go. Yes I am a developer, but I don't have much interest in the overhead of building new React components for every blog post. I hope to establish a somewhat regular posting cadence and would prefer a lightweight way to write a blog post and publish it.

I equally didn't have a lot of interest in building out my own micro-service supported backend to host and serve content. It would have been a reinvention of many wheels and my time could be better spent elsewhere.

I did look at out-of-the-box solutions such as Netlify which would enable content storage in Github wrapped in some nice UX for management. Through prototyping though I discovered it felt a bit clunky and also a bit unnecessary for me. For a multi-authored blog full of non-developer writers, it is a good solution. But as the sole author of this and as a developer, it's a lot of overhead.

I found myself in search of a lightweight, git-managed, developer-friendly solution that doesn't fully exist in the wild so I decided to have a little fun and craft my own.

**Markdown** continuously popped into my head as a flexible and well established means for writing styled software documentation. Through some searching, I discovered the **Gray Matter** and **React Markdown** libraries which offer markdown parsing and markdown rendering in React-based applications. Running with this, I designed and implemented a blog content pipeline which supports authoring blog posts in markdown files (with styling, etc.), processing them at build time into JSON data containing the original markdown, and then grabbing the markdown out of the JSON and rendering it within a React wrapper.

Bingo, a stylable, repository stored, low overhead means for authoring blog posts and publishing them through a simple site deployment. And a good testament to not shy away from lightweight custom solutions if you have custom requirements.

### Package Management

Sometimes it can feel like there are more **software package managers** in the world than there are people. I've never actually counted them both up and compared, but I assume it's coin flip for which is the winner.

I'm using `yarn` as my package manager because it’s reliable and fast and it works. Also I chose it because I chose it and I hope you can live with that. Jokes aside, package management is a crucial piece of software solutions and it enables leveraging many open-source libraries that can save you so much time. Get familiar with a manager and learn to use it rather than re-invent the wheel whenever you need to roll.

### Dynamic, But Static, URL-Friendly Content?

Let’s clear up a common misconception: static sites can still have dynamic content and dynamic URLs. This is a friend, not a foe. And it’s actually quite powerful.

Even though my site uses static generation (SSG), that doesn’t mean all the content is fixed at build time. Nor does it mean I need a separate file for every blog post. Enter: the slug.

“Slug” has two meanings here:
1. A **URL-friendly string** which provides great SEO web addresses. Look at the URL of this blog post. That hyphenated thing at the end, that's a slug.
2. In frameworks like **Next.js**, a `[slug].tsx` file represents a **dynamic route template**. It's like a reusable component that generates a unique page for each slug. If you're a developer, think of `[slug]` like a class, and each post is an instance—dynamically rendered, but still statically generated at build time.

This setup gives me the best of both worlds. Clean, scalable URLs and fast, cacheable, serverless performance.

### AWS

Someone talking about the AI boom may forget to mention Amazon (sorry that was mean), but when it comes to this tech stack I promise I didn't forget Amazon and AWS. If you've gotten this far, welcome to the cloud.

I've touched on it a bit already, but I've intentionally designed out and avoided any complex backend for this website. There truly isn't a need and I try to default to the KISS principle as often as possible. KISS being keep it simple, stupid. If you haven't heard of that, it's a design principle coined by the US Navy in the 1960s and is now widely/wisely adopted in tech. There's no need to overcomplicate something that's not complicated.

#### S3 + Cloudfront
So when it comes to this website's backend, it's rather simple. The build-generated HTML is stored in an S3 bucket that's configured for website hosting. In front of that, there's a Cloudfront distribution which acts as my global CDN (content delivery network) to cache and deliver content quickly.

A quick tangent - if you're not totally familiar with what the cloud actually is, you can think of it as a bunch of computers in a warehouse somewhere that your devices connect to over the internet and talk to. Amazon, Microsoft, Oracle, Google and others all have built these large warehouses (data centers) and companies rent the computers (servers) located there to run their programs on the internet. This website is actually hosted from Northern Virginia in Amazon's `us-east-1` region. Imagine if you lived in Australia and you wanted to look at this website on your phone. You'd enter the URL in your phone's browser, and then your phone would have to send a signal around the world to Virginia asking for this blog post. Then the computer in the Virginia data center would grab this blog post and send it all the way back around the world to Australia. The speed of light is fast, but doing something like this can legitimately introduce a delay that users notice and would perceive as slow / as a bad website. Now imagine you refresh the page from Australia, and again you have to travel around the world and back to get the same blog post you just asked for 5 seconds ago. That's a waste, right?

This is exactly what a CDN is for and why I'm using one. It's a bunch of smaller computers that are scattered all over around the world and can save information temporarily for faster access. Maybe the first time you try to load this blog post from Australia, you have to wait for it to get retrieved from Virginia. But if you refresh the page, the little computer nearby you in Australia remembers you already retrieved this blog post, and instead of going all the way back to Virginia to re-retrieve it, you simply get it from the Australian computer.

Bottom line, it's important not to shy away from added complexity if there's a true reason for it, and in this case, a CDN is the perfect solution for building a fast website.

#### The alexfischman.dev URL

I'll spare the boring details but an honorable mention to **Route 53** and **ACM**. I leverage these Amazon AWS services for domain configuration and to manage the certs needed to access this website securely (HTTPS) at alexfischman.dev.

#### Infrastructure as Code (IaC)

Quick plug: IaC is extremely important for managing cloud resources. It ensures reproducibility as well as version controlled changes to critical infrastructure to support my site. I promise you, you don't want to be in the business of manually making infrastructure changes in the AWS Console (or equivalent cloud hosting UX). You will forget a step at some point and risk down time.

I manage everything related to this site with **AWS CloudFormation**. You define what resources you need along with their configurations in YAML templates, and then deploy those templates to create/modify/delete the cloud resources. So in my case, everything related to S3, Cloudfront, DNS records/zones, and Certs is all defined in YAML for easy modification or re-deployment (as needed).

## The Development Process

Congratulations, you made it out of the tech stack doldrums and onto what this looks like in practice. What is my process for writing this code? How do I ensure a change doesn't break the website? What does it actually look like to update the live content on the website?

### Discipline, Discipline, Discipline

It's so much easier to reach your destination when you love the journey. Sure it's cliche but it's absolutely true in terms of your software development journey. Take the time to define your processes. Reflect on what tedious tasks you may have in those processes and then invest in automating them. Apply discipline to your project, and then apply discipline to applying discipline to all your projects. There may be pain at first but soon you'll reach that runner's high and truly be off to the races and towards your finish line.

Yes, I really tried hard to pull your attention back in because I truly believe this is so important, and that you absorb what this discipline actually looks like in software development. Here we go.

### Where Does The Code Live?

If you have a technical background you're well aware of Git and GitHub (plenty of resources online if not). I also heavily plug into GitHub's DevOps functionality including Repos, Issues, Actions, Secrets, Branch Policy, etc. You'll get a clearer picture of this as you read on.

### Developer Workflow

This can be thought of as a developer's routine. What are the things they always do every time they go to write some new code? A good workflow can make a developer's life so much easier and reduce the time it takes to make a high quality product.

In my case, I follow this exact process every time I write code for this website:
1. Scope the work - understand what specific change you'd like to make and do not let it get too big, that becomes tough to manage
2. Create a GitHub Issue - title and describe the change you just planned to make and create a specific issue to track the work
3. Checkout a git topic branch per issue - checkout a topic branch to make the changes described in the issue, I follow the branch naming pattern `issue/<issue_number>`
4. Code - implement the change, ideally with testing included
5. Create a PR - create a pull request targeting the development (main) branch which will merge your changes
6. PR status checks - more to come, but status checks (CI builds) are required to pass before a PR can merge
7. Merge PR - once the change is good and passing CI gates, merge the PR which will auto close the issue
8. Deploy - more to come, but a merging PR triggers deployment

I'd recommend developing familiarity with scripting. I personally have a few shell functions that automate branch creation, PR creation, etc. that I rely on for every change I make. A small thing that adds a big quality of life boost.

### GitHub Actions - CI/CD

Earlier I hammered home the need to use IaC, this goes hand in hand with that and is of equal or more importance.

A quick overview of **GitHub Actions** - these are automated workflows that you can configure (in YAML code) which are reponsible for building, testing, and deploying your code directly from GitHub. A very powerful suite of functionality.

GitHub automatically detects these workflows in the `.github/workflows` directory and actions are defined as YAML templates.

### Continuous Integration (CI)

CI pipelines are responsible for integrating your changes (that exist in a pull request) into the main development branch. They are an absolute must in order to have a stable and high quality codebase. A CI pipeline should build, validate, and test your changes and ensure that your change does not regress any existing code/functionality in the codebase.

My primary CI pipeline is [web-ci](https://github.com/afisch710/alexfischman.dev/blob/development/.github/workflows/web-ci.yml) and is responsible for validating any changes I make to this website. As mentioned, this is automatically triggered to run when I create a PR and my PR cannot merge until this passes. Assuming proper validation is defined in a CI, it can guarantee your codebase remains in a healthy state.

### Continuous Delivery (CD)

CD pipelines are responsible for automating the process to release/deploy code. This is another extremely important workflow as it guarantees reproducible and stable deployment processes for updating your product.

For me, my CD pipeline is [web-cd](https://github.com/afisch710/alexfischman.dev/blob/development/.github/workflows/web-cd.yml). Once a PR merges, this is automatically triggered to deploy my change to become live on this website. This entails:
1. Building the application which generates all the static HTML we've previously discussed
2. Post build processing that organizes and cleans up the build output and getting into a state that's ready for deployment
3. Deploying the AWS CloudFormation stack to ensure all IaC changes for this website are immediately updated in AWS
4. Uploading the prepared build output (from step 2) to the S3 bucket which hosts this website statically
5. Invalidating the CloudFront CDN to ensure no old files are leftover that would not reflect the new change

Additionally, I have a couple CI/CD pipelines for the other IaC defined resources to ensure changes to them are protected and automated as well.

### The Result

What is the culmination of all the above? Shipping an update is as simple as creating an issue, writing the product code, and merging a PR. Within a few minutes it will then be live on this website and is as pain free as can be.

## Using AI Tools

If you are a developer, I hope you are utilizing every AI developer-assisting tool available to you. You will see a productivity boost on the order of multiple magnitudes. But do not fall for the trap. **Vibe coding** is always tempting, but in my opinion it's a dangerous trap that's too easy to fall into. Understanding your code and your product remains imperative. As is remaining in charge and responsible for your codebase.

Given that disclaimer, I have been and continue to be a strong strong advocate of tools like **Cursor** and **ChatGPT** for development. I was an early adopter of this technology and over the last 1-2+ years the progress being made that I witness firsthand daily is out of this world. I do enjoy testing the limits of artificial intelligence and how it can supplement my life, and particularly when it comes to software engineering it feels as if those limits are expanding as quickly as the universe is.

There are sizable portions of this codebase that I have co-developed with OpenAI's **o3-mini**, **o3**, and **o4-mini**, as well as Anthropic's **Claude Sonnet 4**. The ability to oversee their development of tedious or even complex coding tasks is a very high demand skill and I'm a firm believer that it will continue to be for the foreseeable future. Now as I step off this small soap box, I'll reiterate that human ingenuity + creativity in combination with artificial intelligence and wrapping frameworks/tooling opens some incredible doors, particularly at this point in time. And I could talk about this for hours so please reach out if you share a similar vested interest or passion.

## That's A Wrap, Ship It

This is the first blog post I have ever written and it's been a great time. If you made it here, thank you for taking some time out of your day to learn about me and one of the things I've been working on. Software engineering has been a big part of my life and I'll continue to share some of my perspectives and experiences with it in the future. I also would love to branch this blog out into other areas I love, like the intersection of tech and business, my startup Smarter Weather, and any other rabbit holes I may find myself down.

I'd love to hear any feedback you may have, to answer any questions you have about this website, or to just have a fun conversation with you. Feel free to contact me at any of the social links below. And thanks for reading!

A technical breakdown of my website intertwined with lessons I've learned along the way

Introducing Pourtle

Moving your content between your devices

How I Built alexfischman.dev

A technical breakdown of my website intertwined with lessons I've learned along the way